Make library symlinks relative
This allows distributions to be more easily relocatable, such as when bottling this library in Homebrew.
Hm... if I understand this correctly, it will create a symlink to the folder where the http parser was built. Which means that when the development directory will be removed - the links will be dangling.
Is it expected? Why is it useful?
Symlink targets are always in reference to the location of the symlink file itself, so since the symlink file location is inside of $(LIBDIR), the target will implicitly point to $(LIBDIR) as well. In other words, this change should have no functional impact, except that if the files were moved after installation (if, for example, this library were bundled with some other piece of software that was meant to be portable, for instance) the symlink would not be broken.
As it stands now, if the absolute path to the library changes due to the folder being moved/relocated, the symlink will point to the incorrect path. This is an issue when "bottling" this library in the Homebrew package manager for OSX. Homebrew builds binaries for many of its packages, and Homebrew supports installation in non-standard prefixes (e.g. anything other than /usr/local/). However, if the binaries contain hardcoded paths or other problems that make them difficult to relocate, those binaries cannot be installed in non-standard prefixes. This patch makes it so that binary builds of this library are easily relocatable.
@jasnell may I ask you to take a look at this?
Yeah, I can take a look. Realistically it won't be until after 4.2.0 is out on monday tho. I have a whole bunch of sniff testing to do to make sure 4.2.0 is solid.
(I'll try to get it sooner than that tho)