docs: "docker compose cp -L" does not dereference symlinks in directory

[pzhlkj6612]

Hi!

Before:

$ ls -g -o ./opt/usr/i686-w64-mingw32/bin/
total 14452
lrwxrwxrwx 1       29 Jan 25  2024 ar -> ../../bin/i686-w64-mingw32-ar
lrwxrwxrwx 1       29 Jan 25  2024 as -> ../../bin/i686-w64-mingw32-as
lrwxrwxrwx 1       34 Jan 25  2024 dlltool -> ../../bin/i686-w64-mingw32-dlltool
lrwxrwxrwx 1       29 Jan 25  2024 ld -> ../../bin/i686-w64-mingw32-ld
lrwxrwxrwx 1       29 Jan 25  2024 ld.bfd -> ../../bin/i686-w64-mingw32-ld
lrwxrwxrwx 1       29 Jan 25  2024 nm -> ../../bin/i686-w64-mingw32-nm
lrwxrwxrwx 1       34 Jan 25  2024 objcopy -> ../../bin/i686-w64-mingw32-objcopy
lrwxrwxrwx 1       34 Jan 25  2024 objdump -> ../../bin/i686-w64-mingw32-objdump
lrwxrwxrwx 1       20 Dec 27 18:12 protoc.exe -> protoc.exe-3.21.12.0
-rwxr-xr-x 1 14797564 Dec 27 18:12 protoc.exe-3.21.12.0
lrwxrwxrwx 1       33 Jan 25  2024 ranlib -> ../../bin/i686-w64-mingw32-ranlib
lrwxrwxrwx 1       34 Jan 25  2024 readelf -> ../../bin/i686-w64-mingw32-readelf
lrwxrwxrwx 1       32 Jan 25  2024 strip -> ../../bin/i686-w64-mingw32-strip

After:

$ ls -g -o ./opt/usr/i686-w64-mingw32/bin/
total 44776
-rwxr-xr-x 1  1164680 Jan 25  2024 ar
-rwxr-xr-x 1  1805360 Jan 25  2024 as
-rwxr-xr-x 1  1201736 Jan 25  2024 dlltool
-rwxr-xr-x 2  1752048 Jan 25  2024 ld
-rwxr-xr-x 2  1752048 Jan 25  2024 ld.bfd
-rwxr-xr-x 1  1157440 Jan 25  2024 nm
-rwxr-xr-x 1  1283528 Jan 25  2024 objcopy
-rwxr-xr-x 1  2642464 Jan 25  2024 objdump
-rwxr-xr-x 2 14797564 Dec 27 18:12 protoc.exe
-rwxr-xr-x 2 14797564 Dec 27 18:12 protoc.exe-3.21.12.0
-rwxr-xr-x 1  1164712 Jan 25  2024 ranlib
-rwxr-xr-x 1  1022864 Jan 25  2024 readelf
-rwxr-xr-x 1  1283528 Jan 25  2024 strip

Ref:

• docker cp --follow-link does not work as expected moby/moby#30213

[pzhlkj6612]

Using ./scripts/tools.sh compose-cmd ... looks better IMO.

[pzhlkj6612]

I have a question: Are we making a sysroot? If so, the CMAKE_SYSROOT should be configurable.

ra2yrcpp/toolchains/mingw-w64-i686.cmake

Line 4 in 860efec

set(CMAKE_SYSROOT /usr/${TOOLCHAIN_PREFIX})

After patching the toolchain cmake file, I still need to specify PROTOC_PATH to $PWD/opt/bin/protoc. If we will have a configurable sysroot, maybe we can directly copy "protoc" to opt/usr/i686-w64-mingw32/bin (or ln -s ../../../bin/protoc ./opt/usr/i686-w64-mingw32/bin/protoc). After that, building on the host may become easier.

[shmocz]

The commit itself looks OK, but since it's related to other issues, I have to give this some thought.

The non-Docker build instructions are bit of a mess at the moment.

The toolchain file is primarily for the Docker environment. It's generic enough to also work on my own system, but it's intended to serve more as an example and customized for user's needs.
In a generic Linux environment CMAKE_SYSROOT points at base MinGW toolchain path and is a reasonable default. In the Docker image the protobuf libraries are installed to this sysroot.

Copying the stuff from the Docker image is mostly for convenience, because in practice it'll be always built by the developer.
It'd be best to have instructions for building protobuf on the host machine.
The libprotobuf.a from Docker container only works if the host has a similar MinGW toolchain, MSVC/clang-cl won't work (this is mentioned but could be clarified wrt. Docker).
I'm not sure what'd be an elegant solution for isolated protobuf builds that'd also override possible existing protobuf/protoc from the system.

The protobuf situation is complex and deserves it's own issue. For instance:

• On Linux, protobuf must be built twice: 1) cross-compiling the Windows library libprotobuf.a 2) compiling native protoc.
• protoc version must match libprotobuf.a version
• Should protobuf be updated? Newer protobuf versions don't support CMake, complicating the build process.
• What are the compatibility guarantees for serialized data between different protobuf versions? Can we use newer protobuf in pyra2yr while sticking to older version in ra2yrcpp?