Discussion: move the rhash build to something standard

[hanetzer]

Just a thought, but consider the idea of moving the rhash build from its current custom
configure/Makefile pair to something more standard, say autotools or cmake. It would
require less specialized knowledge (the build system used only here vs build systems
used by just about every major open source library) to update and would probably cut
down on issues like https://bugs.gentoo.org/650840 which was fixed in gentoo/gentoo@8659d46

I'm personally willing to put in the work myself, if given a decision on what to use. I'm
good enough with both autotools and cmake to do the job.

[Polynomial-C]

Porting rhash to cmake would create circular deps for people who want to bootstrap their systems as cmake requires rhash since version 3.8.0-rc1.

[hanetzer]

@Polynomial-C fair enough, then I would suggest an autotools build, then, since it would require
the least amount of workflow adjustment for package maintainers (still a ./configure script, just
one that doesn't make someone think its an autotools package when it isn't) I think.

[rhash]

Duplicate of #5.

[hanetzer]

So it is. This is a bit of a pity, however, it seems that compiling for mingw-w64 on gentoo
with crossdev ends up with executables without the *.exe extension and libraries with a
*.so extension, despite actually being pe32 binaries.

[rhash]

@hanetzer, try passing the --target=x86_64-w64-mingw32 option to the configure

[hanetzer]

@rhash would passing the triplet for standard gnu/linux targets work as well? Because, I'm seeing that --target is not being passed at all, so this could be a reasonable fix.

[hanetzer]

Works better, but something else is is wrong on the rhash side of things; a symlink gets made,
for what I assume is soname stuff, and it links to a file that doesn't exist in the location expected.

/etc/rhashrc
/usr/bin/ed2k-link.exe -> rhash.exe
/usr/bin/edonr256-hash.exe -> rhash.exe
/usr/bin/edonr512-hash.exe -> rhash.exe
/usr/bin/gost-hash.exe -> rhash.exe
/usr/bin/has160-hash.exe -> rhash.exe
/usr/bin/librhash.dll
/usr/bin/magnet-link.exe -> rhash.exe
/usr/bin/rhash.exe
/usr/bin/sfv-hash.exe -> rhash.exe
/usr/bin/tiger-hash.exe -> rhash.exe
/usr/bin/tth-hash.exe -> rhash.exe
/usr/bin/whirlpool-hash.exe -> rhash.exe
/usr/include/rhash.h
/usr/include/rhash_torrent.h
/usr/lib/librhash.dll.a
/usr/lib/librhash.so -> librhash.dll
/usr/lib/pkgconfig/librhash.pc

On mingw-w64 the actual dll's get stuck into /bin or /usr/bin, so a straight link in the
lib dir does not work.

[rhash]

I think the `install-lib-so-link` and `install-so-link` targets should not be run for mingw platform. So use just `make install` (or `make install install-gmo` for l10n).

[rhash]

would passing the triplet for standard gnu/linux targets work as well?

The --target option is used for cross-building and accepts triplets like x86_64-linux-gnu.

[hanetzer]

@rhash got it fixed for gentoo/gentoo@00de856, however I still believe it needs to be
moved to something more standard. from #5 I can see you don't much care for autotools,
which is fair enough, and cmake would prolly make for a bit of trouble as @Polynomial-C
has said. Have you considered meson? It allows you the subdirectory based layout you mentioned you would prefer.

[JPeterMugaas]

Personally, I would favor CMake since I happened to have experimented with it. I got stuck on some things, I got too hung up on bindings, and a computer died. But it's very easy to do cmake plus it does have some built in testing functions that can be used. And actually the concerns about bootstraping (cmake depends upon rhash) are already a concern because json-cpp uses cmake for it's build and cmake depends upon json-cpp. Personally, I prefer cmake because you wouldn't have to do an autoreconf -fiv to make another set of build files.

If you want, I can restart the effort. I have some cmake script work here ( FLIF-hub/FLIF#494 ).

[hanetzer]

@JPeterMugaas not my call personally, but I'd be happy with anything standard with known
idiosyncrasies instead of a homebrew configure script that pretends to be autotools, where
what is expected to happen actually does happen.

[JPeterMugaas]

And the thing I like about CMake serves several purposes in the build process. The first is to generate the Makefile, then it also provides some helper functions, it can be invoked with script name or commands to do various hard to do tasks in CMake in a more cross-platform way, plus, it could bypass the shell where command synentics can be different, plus, I'm convinced that would drop dependencies on some Linux specific things such as grep (yes, I know there are Windows versions).

And another advantage to all of this is that the files created by the build process itself are separate from the original source-code.

In any case, I think I have made a very good argument for using CMake over autoconf.

[hanetzer]

Yep, ditto for meson tho. Though to be fair, python isn't quite as nice to have on windows, which is
needed for meson at the moment.

[JPeterMugaas]

I plan to get started later today on this CMake-based build system. It may take several days but I think it's worth doing. Personally, I'm not familiar with meson.