Headers include paths aren't relative..

[Niadb]

I don't understand what is going on with zstds header include structure, the paths are wrong and seem to assume that various directories are globally available..

Example:
cover.h in dictBuilder has
#include "mem.h"
#include "pool.h"

Neither exists in the same folder as cover, so I have to fix these by changing to

#include "../common/mem.h"
#include "../common/pool.h"

Then fix it again when I update zstd, after a few years I just have to ask..why?

[lazka]

The build system adds "common" to the include path:

zstd/lib/Makefile

Line 22 in ff6350c

CPPFLAGS+= -I. -I./common -DXXH_NAMESPACE=ZSTD_

[Niadb]

This is C++, nobody uses the same build system..(we don't use makefiles on windows..)

Even if I have my project for zstd add common(which I did, so zstd itself compiles ok), these paths are exposed to other projects when they include zstd headers, so they also now need to globally add the common folder, that just seems broken..

[lazka]

(disclaimer: not a zstd dev) I don't think cover.h is supposed to be a public header so it shouldn't be exposed to other projects.

[stati64]

We edit them also. Why crave ambiguity?

[felixhandte]

@Niadb,

Our expectation has been, I think, that consumers of zstd will use it having been built separately (either by installing it as a system package or by building it on its own and then linking the resulting artifacts into their application). Sourced in either of those ways, zstd will have been built using any of the build configurations provided in the project (Make, CMake, Meson, Buck, Visual Studio), all of which are set up to support this include pattern.

That being said, this is not the first report we've had of this sort. I'm personally not opposed to re-writing includes to be relative. Feel free to put up a PR.

[felixhandte]

Fixed by #2103.