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.

[rhash]

The project has the MS VC project file (another build system), and it's in the build/ directory now.

CMake is not bad choice for an alternate build-system, but the CMakeList.txt should also be placed into the build directory. As for meson, most of users will not understand what it is, imho. Also supporting too many build systems will become a pain, when source tree grow.

I plan to leave the current 'manual configure script' as the main build system, to minimize build-dependencies and to avoid cmake circular dependency.

[Polynomial-C]

I've looked into the build system of cmake sources and found that you can already disable usage of system rhash by setting -DCMAKE_USE_SYSTEM_LIBRHASH=OFF. So the circular dependency can be avoided in some degree.

[Polynomial-C]

Regarding meson, I think it's becoming rapidly well known and used lately. gstreamer, gnome and Xorg have switched or are switching their build systems to meson, just to name a few well known projects. Meson is fast, rather uncomplicated and its only dependency is python (because its a python project).

[hanetzer]

@Polynomial-C I would agree that meson is a very good candidate, if you want to avoid the cmake dep cycle. Though as you mentioned, the -DCMAKE_USE_SYSTEM_LIBRHASH=OFF option makes that
less of an issue.

[rhash]

From http://www.rojtberg.net/1481/do-not-use-meson/

Nowadays the difference between Meson and CMake is just a matter of syntactic preference. The Meson authors seem to agree here.

The actual criterion for selecting a build system however should be tooling support and community spread. CMake easily wins here:

After the introduction of the server mode it got native support by QtCreator, CLion, Android Studio (NDK) and even Microsofts Visual Studio. Native means that you do not have to generate any intermediate project files, but the CMakeLists.txt is used directly by the IDE.

On the community spread side we got e.g. KDE, OpenCV, zlib, libpng, freetype and as of recently Boost. These projects using CMake not only guarantees that you can easily use them, but that you can also include them in your build via add_subdirectory such that the become part of your project. This is especially useful if you are cross-compiling – for instance to a Raspberry Pi.

I'm against supporting too many build systems (that means fixing bugs, updating changed paths and libraries). So, after giving it some thought, I vote for replacing current MS VC project by more universal CMakeLists file.

[JPeterMugaas]

Personally, I think the more universal cmake might be a good choice for a replacement. I have been working on something here and I have made a pull request so others may comment on the work.

#71

[JPeterMugaas]

I have gone ahead and done the basic stuff for this. The cmake also includes a number of tests that are equivalent to the old bash .sh stuff. And this also includes Doxygen support for API documentation since cppdoc since that is no longer available from a reliable source and I can't download the source-code. I finally was able to confirm that the source-code does build even on Linux.

[diizzyy]

I agree that it would be nice, meson is like mentioned earlier a better candidate to avoid bootstrapping issues and easier to fix issues such as #238

[haampie]

+1, please just use autotools on linux/darwin/bsd, it works, it's dependency free, and the current "build system" is what you get when you try to reinvent the autotools wheel, it's full of issues.