Installing on Mac: the fudgening

[billetd]

BUG

Thought I would document my most recent (successful) attempt at installing RST on a Mac, and the main issue I encountered. Currently this process worked for me on MacOS Ventura 13.4.1c.

Priority

Minor - typo, incorrect naming, fails in a specific uncommon situation

RST version

No. Branch containing the bug (e.g. develop): Develop

Example of the bug

Everything went smooth during install, right up to running make.code. As many people have experienced before, RST seems to have trouble finding certain files. I noticed that all of the files that would come up as "not found" are related to the environment variables defined in base.bash.

On a clean install for example, running make.code for the first time encounters the error:

cc -Wall -pedantic -O3 -D_GNU_SOURCE -D_DARWIN -I/opt/local/include -I/Users/danielbillett/rst-develop/include/base   -c png.c
png.c:32:10: fatal error: 'png.h' file not found
#include <png.h>
         ^~~~~~~
1 error generated.
make: *** [png.o] Error 1
Compilation Aborted.

For me, png.h was exactly where I pointed the XPATH environment variable to in base.bash. You can get past this issue by going directly into png.c in codebase/base/src.lib/graphic/fbuffer.1.19/src/png.c and changing:

#include <png.h>

to

#include <YOUR_X11_PATH/include/png.h>

This whole process continues for a few .h files (I had to manually change 5 total) that RST can't find, with a workaround being to point the .c file manually to the right place. The problem seems to be related to RST not properly looking where you define XPATH, NETCDF_PATH, and CDF_PATH in base.bash. Even if you edit those environment variables to point in the exact location of the file that RST can't find, it won't work. Performing echo $XPATH does however return the path you put in, so it doesn't seem to be a Unix issue.

Plot twist

Those paths do actually work correctly when you get to the part of make.code where libraries are compiled. I did find small issue with the Mac install documentation though. In order for RST to get access to the library files for CDF, NETCDF, and X11, those paths need to point to the respective parent directories, not the include sub folder as the documentation suggests. I'll make a PR for that after I post this issue.

TL;DR

RST doesn't look in the right place for .h files associated with X11, CDF, and NETCDF when the environment variables in base.bash are set correctly. RST does however use those variables to find the library files correctly.