Headers for non-packaged software

I have some libraries in development, and since those are changing pretty much on a daily basis I see no reason to create packages for now. Instead, I stored links to their headers and libs in /boot/home/config/non-packaged. That way, applications that use such libraries have access to the latest version without adding anything special in the Makefiles.

This works very well for years, but I’m not sure it is the “right” way because, by default, the non-packaged directory does have a lib subdirectory but not a headers subdirectory (as /system/develop does).
What I did was to manually create ~/config/non-packaged/include and use it to store links to my libraries’ headers ever since. Even though ~/config/non-packaged seems to be the perfect candidate for this, the fact that it lacks a headers subdirectory by default makes me think if I am missing something here.

It seems to be the right way to do this. We should probably create the directory by default.

6 Likes

It’s actually supposed to be ~/config/non-packaged/develop/headers. You can see the full list by running: findpaths B_FIND_PATH_HEADERS_DIRECTORY. There are several other directories that aren’t created by default including /var/spool, various subdirs in /system/non-packaged and ~/config/non-packaged for add-on directories, etc…

1 Like

Most build systems are adjusted to “fix” those “include” directories when the prefix is set to ~/config/non-packaged, some however use hardcoded paths and will use the above:

What you could do is try an export for PKGCONFIG_PATH:

export PKG_CONFIG_PATH+=/boot/home/config/non-packaged/lib/pkgconfig/

1 Like

Useful information. I didn’t know about findpaths.
So, after running findpaths B_FIND_PATH_HEADERS_DIRECTORY and findpaths B_FIND_PATH_LIB_DIRECTORY, I guess the “canonical” system directories for packaged libraries are:

/boot/system/develop/headers and /boot/system/lib

while for user’s non-packaged libraries the corresponding directories are:

~/config/non-packaged/develop/headers and ~/config/non-packaged/lib

where the headers directory is not present by default for some reason, but the lib directory does exist.
If that’s correct, the absence of ~/config/non-packaged/develop/headers is a bit confusing. I’m not surprised some people used ~/config/non-packaged/include instead, as @Begasus pointed out. It also means I should (slighty) modify many Makefiles (but I have none to blame other than myself, because I should ask before going that far).

There is also a third directory and the layout is supposed to match the system ones, meaning…

~/config/non-packaged/develop/headers is for the include files

~/config/non-packaged/develop/lib is where the linker should look for libraries when building software. This one is from B_FIND_PATH_DEVELOP_LIB_DIRECTORY

~/config/non-packaged/lib is where the runtime_loader looks for libraries

1 Like

Why is that, if there is no buildsystem involved (eg autotools/cmake/meson …) and just regular Makefile(s), you could check if they provide variables like PREFIX, BINDIR, LIBDIR and maybe even INCLUDEDIR, you could point that to the appropriate target in build and install time like:

make INCLUDEDIR=/boot/home/config/non-packaged/develop/headers

Without knowing the process it’s hard to tell, but it shouldn’t be a major problem.

PS, in that example I adjusted the path afterwords in my script to use the correct paths, no more “include” directory anymore.

1 Like

I almost never provide include and lib directories when invoking make. Instead, my Makefiles detect the operating system running and set include and lib directories accordingly. That way the same Makefile can be used in Haiku, FreeBSD, GNU/Linux, basically any *nix-like operating system. I find it very convenient. Of course, developing native Haiku applications is a different story. In that case Makefiles are simpler because I don’t need to detect the operating system.

Modifying my existing Makefiles is not a problem, more like a chore. I just assumed headers should go to ~/config/non-packaged/include, and that was a mistake (even though it works). But luckily the sed utility can be handy: all is needed is to just replace include with develop/headers using sed.

Still, I’m pretty sure I’m neither the first nor the last who did that mistake. I think ~/config/non-packaged/develop/headers should be there by default, just like ~/config/non-packaged/lib.