how do cross platform C projects ensure their included headers are present in the same prefix when compiling on different machines?

For example, today I found that using a package manager gave me one prefix, e.g. foo/bar.h where foo is the value in question. then compiling with default ./configure options for the same package, gave me a different value, e.g. baz/bar.h

Right now I'm just resorting to ensure any required libs are compiled from source each time.

Follow

where cross platform just means developing on different distros or OS. e.g. i have the same project but work on ubuntu, arch, windows, macOS. but the package managers evidentially prefix this header file location with a different folder name?

my current approach works, but its kind of annoying to me, given that each OS has its own package manager with some slightly different folder name. is this a problem with *-dev/header packages for other libraries too? i feel i'm missing something simple

· · Web · 1 · 0 · 0

@metasyn I think autotools has options for this?? But multi output packages like Alpine's -dev AFAIK don't require you to install anything in any special place, you just install everything into some prefix and then it splits that file tree up.

What do you mean by "where foo is the value in question"? What is foo actually?
Can you link to some code?

@csepp when I install ImageMagick - I think it's prefixed as "wand" when I got install the debian package. but installing from source without prefix gives "MagickWand" for the folder like I'm using it here I'm using it here git.sr.ht/~metasyn/memex/tree/

it's not complicated to fix immediately but I don't really know how ppl normally deal with stuff like this. maybe just use build tools like you suggest as soon as you need anything 😅

@metasyn Hmm. Odd. Here is Alpine's build script for comparison, maybe you are using a different flag:
git.alpinelinux.org/aports/tre
Package contents: pkgs.alpinelinux.org/contents?

(aside: All this Docker stuff and manually managed build scripts really gives me "this shouldn't be this complicated" vibes. Have you tried Nix? I'd recommend Guix, but I see you're doing something npm related (my condolences) and npm isn't in Guix yet.)

@csepp turns out its just a version difference; the debian package is on IM 6 but I was using 7, and they have different folder naming conventions between versions i guess.

re: nix/guix, that looks a bit too complicated to me for right now. it would be nice to pin random libraries/packages so i don't run into things like this though. maybe someday! i think i'll try to do my dotfiles first before using nix in project... the npm thing is just for eslint + config so its not important at all

Sign in to participate in the conversation
Merveilles

Merveilles is a community project aimed at the establishment of new ways of speaking, seeing and organizing information — A culture that seeks augmentation through the arts of engineering and design. A warm welcome to any like-minded people who feel these ideals resonate with them.