pcre2 about boxes

[tsjensen]

Right, since v2.0.0, pcre2 is a requirement.
You can find detailed build instructions on the website.

[tsjensen]

Since you're on Mac, you might also be interested to install via brew, or look at their boxes formula for additional inspiration on how to compile yourself.

[rwmitchell]

I don't use brew. If the source doesn't compile, I don't use it. Even with libpcre2, this doesn't

LDFLAGS and CFLAGS are ignored by the Makefile:

printf "%s\n%s\n" $CFLAGS $LDFLAGS
-I/Users/USER/local/include
-L/Users/USER/local/lib

(zsh, both are exported)

make used ```gcc -I. -I../src -Wall -W -O -c -o parser.o parser.c````

After changing src/Makefile to use the environment CFLAGS, it still generated errors in parser.y.

For a 'just for fun' program, this isn't worth it. Thanks anyway.

[tsjensen]

It appears you are setting CFLAGS and LDFLAGS in your shell before calling make. This wouldn't work because they are set in the Makefile, too. We have CFLAGS_ADDTL and LDFLAGS_ADDTL for adding arguments to compiler and linker calls.

I don't have access to a Mac to try and reproduce your problem. On Linux, when you install libunistring-dev and libpcre2-dev, headers and libs are already placed where they are found by the default settings.

[rwmitchell]

If your Makefiles used: $(eval CFLAGS := $(CFLAGS) -I. -Iregexp -Wall -W $(CFLAGS_ADDTL)) then it would use the user supplied value in addition to yours. There is probably even a better way.

You can't possibly know the include path a user has used for a separately installed library. Requiring them to edit the Makefile is poor method to fix it.

[tsjensen]

You can't possibly know the include path a user has used for a separately installed library. Requiring them to edit the Makefile is poor method to fix it.

It's actually not required to edit the Makefile. You can type something like this:

CFLAGS_ADDTL=-I/Users/USER/local/include LDFLAGS_ADDTL=-L/Users/USER/local/lib make

Let me know if stuff works for you now. We seem to have drifted somewhat from the original topic of runtime dependencies.

[rwmitchell]

Neither of those are standard nor listed in any of the readme files ( that I searched anyway ). If it isn't documented and you're doing something non-standard, you can't expect people to set it properly or know they need to set it.

If you just used the standard vars properly, you wouldn't need some hacky method.

[tsjensen]

Neither of those are standard nor listed in any of the readme files

Good point! I added that information to the FAQ.