lnav fails to install: error: invalid command-line arguments, reason: -i excludes -t

[barracuda156]

To begin with, the port does not respect Macports compiler settings, since nothing sets CC_FOR_BUILD. This can be fixed by:

--- src/Makefile.am	2023-07-03 12:16:02.000000000 +0800
+++ src/Makefile.am	2024-02-04 12:48:05.000000000 +0800
@@ -497,7 +497,7 @@
     $(PLUGIN_SRCS)
 
 ptimec$(BUILD_EXEEXT): ptimec.c
-	$(AM_V_CC) $(CC_FOR_BUILD) $(CPPFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) -g3 -o $@ $?
+	$(AM_V_CC) $(CC) $(CPPFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) -g3 -o $@ $?
 
 if HAVE_RE2C
 RE2C_FILES = data_scanner_re.cc log_level_re.cc

--- tools/Makefile.am	2023-07-03 12:16:02.000000000 +0800
+++ tools/Makefile.am	2024-02-04 12:42:06.000000000 +0800
@@ -2,7 +2,7 @@
 all-local: bin2c$(BUILD_EXEEXT)
 
 bin2c$(BUILD_EXEEXT): bin2c.c
-	$(AM_V_CC) $(CC_FOR_BUILD) $(CPPFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) -g3 -o $@ $? -lz
+	$(AM_V_CC) $(CC) $(CPPFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) -g3 -o $@ $? -lz
 
 EXTRA_DIST = \
 	bin2c.c

However, eventually the build still fails:

/opt/local/bin/g++-mp-13 -std=c++14  -pipe -Os -D_GLIBCXX_USE_CXX11_ABI=0 -arch ppc       -L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -lMacportsLegacySupport -arch ppc -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/usr/local/lib -L/usr/lib -o lnav lnav.o lnav.events.o lnav.indexing.o lnav.management_cli.o file_vtab.o libdiag.a libdatascanner.a base/libbase.a formats/logfmt/liblogfmt.a fmtlib/libcppfmt.a third-party/scnlib/src/libscnlib.a pcrepp/libpcrepp.a pugixml/libpugixml.a tailer/libtailerservice.a tailer/libtailercommon.a tailer/libtailerpp.a yajl/libyajl.a yajlpp/libyajlpp.a third-party/base64/lib/libbase64.a -lreadline -lncursesw -lsqlite3 -larchive -L/opt/local/lib -lcurl -lpcre2-8 -larchive -lbz2 -lz -lpthread 
/opt/local/bin/g++-mp-13 -std=c++14  -pipe -Os -D_GLIBCXX_USE_CXX11_ABI=0 -arch ppc       -L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -lMacportsLegacySupport -arch ppc -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/usr/local/lib -L/usr/lib -o lnav-test lnav.o lnav.events.o lnav.indexing.o lnav.management_cli.o test_override.o file_vtab.o libdiag.a libdatascanner.a base/libbase.a formats/logfmt/liblogfmt.a fmtlib/libcppfmt.a third-party/scnlib/src/libscnlib.a pcrepp/libpcrepp.a pugixml/libpugixml.a tailer/libtailerservice.a tailer/libtailercommon.a tailer/libtailerpp.a yajl/libyajl.a yajlpp/libyajlpp.a third-party/base64/lib/libbase64.a -lreadline -lncursesw -lsqlite3 -larchive -L/opt/local/lib -lcurl -lpcre2-8 -larchive -lbz2 -lz -lpthread 
if test -w ./internals; then \
		env DUMP_INTERNALS_DIR=./internals DUMP_CRASH=1 ./lnav Makefile; \
		mv ./internals/*.schema.json ../docs/schemas; \
	fi
✘ error: invalid command-line arguments
 reason: -i excludes -t
mv: rename ./internals/*.schema.json to ../docs/schemas/*.schema.json: No such file or directory
make[3]: *** [all-local] Error 1

[ryandesign (Ryan Carsten Schmidt)]

Probably upstream had good reason for using CC_FOR_BUILD instead of CC here so the fix is not to patch that but for the port to set CC_FOR_BUILD (and CPPFLAGS_FOR_BUILD and LDFLAGS_FOR_BUILD if any of those are necessary). Typically, the *_FOR_BUILD variables would be used for programs that are built to be run during the build by the build machine, as opposed to things being built to be installed and used on the end-user machine. If you believe upstream was incorrect to use the *_FOR_BUILD variables here, please share the upstream bug report URL or pull request or commit so we can check up on it.

[barracuda156]

Replying to ryandesign:

Probably upstream had good reason for using CC_FOR_BUILD instead of CC here so the fix is not to patch that but for the port to set CC_FOR_BUILD (and CPPFLAGS_FOR_BUILD and LDFLAGS_FOR_BUILD if any of those are necessary). Typically, the *_FOR_BUILD variables would be used for programs that are built to be run during the build by the build machine, as opposed to things being built to be installed and used on the end-user machine. If you believe upstream was incorrect to use the *_FOR_BUILD variables here, please share the upstream bug report URL or pull request or commit so we can check up on it.

I certainly do not insist that usage of CC_FOR_BUILD is incorrect, but as a matter of fact upstream set-up as it exists now does not work. I actually tried to pass CC_FOR_BUILD via build.env initially, and it was ignored. What is the way to do it correctly?

16. S. I have no clue about the other bug with invalid command-line arguments.

[ryandesign (Ryan Carsten Schmidt)]

Replying to barracuda156:

What is the way to do it correctly?

I don't know this software but here is how it's implemented:

​https://github.com/tstack/lnav/blob/v0.11.2/m4/ax_prog_cc_for_build.m4

It says:

#   The macro sets the CC_FOR_BUILD and CPP_FOR_BUILD macros to anything
#   needed to compile or link (CC_FOR_BUILD) and preprocess (CPP_FOR_BUILD).
#   The value of these variables can be overridden by the user by specifying
#   a compiler with an environment variable (like you do for standard CC).

[barracuda156]

Replying to ryandesign:

Replying to barracuda156:

What is the way to do it correctly?

I don't know this software but here is how it's implemented:

​https://github.com/tstack/lnav/blob/v0.11.2/m4/ax_prog_cc_for_build.m4

It says:

#   The macro sets the CC_FOR_BUILD and CPP_FOR_BUILD macros to anything
#   needed to compile or link (CC_FOR_BUILD) and preprocess (CPP_FOR_BUILD).
#   The value of these variables can be overridden by the user by specifying
#   a compiler with an environment variable (like you do for standard CC).

So apparently no reason not to use just CC. If it can be set to anything, it can be set to the default compiler.