update libraries and move them out of source tree

[darealshinji]

I've been thinking about the .dll and .so files that are shipped with the source code.

• you should probably update them (they're 2 years old)
• you should move those files out of the source tree to avoid large diffs and pulls
• libewf is LGPL so you probably have to put its source code somewhere

I made this repository for testing purposes: https://github.com/darealshinji/quickhash-libs

It includes scripts to build the libraries for Linux and Windows (cross-building on Linux).
The compiled binaries of the latest release versions are available at the release section: https://github.com/darealshinji/quickhash-libs/releases/tag/20231102
By the way, the dll files are linked so that you don't need to ship extra dependencies like libwinpthread-1.dll.

Instead of creating a new repository you can also add libewf as a git submodule, put the binaries on i.e. sourceforce and add a download script to fetch them. The good thing about submodules is that the code is not automatically fetched when you clone the repository.

Edit:

Here's a test branch that replaced the libraries with scripts and adds libewf sources as a submodule: https://github.com/tedsmith/quickhash/tree/submodule-test

[FabioLolix]

libewf is LGPL so you probably have to put its source code somewhere

If it is modifed, from my understanding

[darealshinji]

libewf is LGPL so you probably have to put its source code somewhere

If it is modifed, from my understanding

If I understand this correctly the whole "provide source code (if somebody asks for it)" thing applies to the LGPL licensed part (libewf in this case) if you distribute it along with your program - which is done here. But I think a git submodule or link to a tarball is sufficient; at least it would make it easier to understand which version of the library was used.

[tedsmith]

Thanks for your efforts in streamlining this part. This looks incredibly promising - I especially like that linking aspect which was an area of some headache that I had last time when I first started to add DLL linked functionality. I'll definitely come back to this in preparation for the next version if that's OK. I've put a lot of time and effort in to the last two releases, and family and work life are making that increasingly hard. Just getting v3.3.4 out last night took me about 3 hours - compiling on each platform, then checking they all worked OK; Apple Mac being the biggest headache of course. And more often than not, when I make changes other things then go wrong somewhere else, and I end up in an infinite loop of recompiling and re-packaging. It wears me out and ends up making me frustrated at the process. But when I get a solid chunk of time without distraction, I'll look into your suggestion more and I thank you again for going to such effort to help.

As for the age of the DLL aspect - the two sqlite DLLs for Windows are new as of Sept 2023 and were shipped with v3.3.3. Most of others were compiled for v3.3.1 or v3.3.2 I think, which is indeed a little old now but not so much it would make a huge impact.

The libewf license was considered at some length when I first started using it with QH. From memory, I think I added a lot about it in the comments of QH, and I link to the project, I credit the dev Joachim Metz and others etc. And I think as you point out, the provision of the source code is possible from the links, and if someone asks for it, then they can either go and get it, or I will if I really have to. I think that line of "provide source code (if somebody asks for it)" literally just means "dont conceal that you have it".