[Bug]: Build system smells

[meator]

Version

3.5.2

Describe the problem you're encountering

Most of these can be considered minor issues, but

• Several documentation sources mention a pkg-config dependency. I am under a heavy suspicion that this is a false dependency and that pkg-config is not used anywhere. If it is used anywhere, it is most certainly used wrong (otherwise cross compilation of couchdb would work).

• couchdb/configure

  Lines 337 to 343 in 7839518

  	if [ ! -d "/usr/include/${SM_HEADERS}" ] && \
  	[ -n "${MULTIARCH_NAME}" -a ! -d "/usr/include/${MULTIARCH_NAME}/${SM_HEADERS}" ] && \
  	[ ! -d "/usr/local/include/${SM_HEADERS}" ] && \
  	[ ! -d "/opt/homebrew/include/${SM_HEADERS}" ]; then
  	echo "ERROR: SpiderMonkey ${SM_VSN} is not found. Please specify with --spidermonkey-version."
  	exit 1
  	fi

  This is not how you check for dependencies. This doesn't work well with cross compilation and with systems that deal with includes in a "more creative way" like Nix. Since we have it, why don't we use pkg-config?

  pkg-config --exists mozjs-${SM_VSN}
  

  This of course requires further testing. couchdb seems to support a lot of systems, some of them might not have pkg-config working. More than one dependency detection mechanism might be needed, but pkg-config should be the first method tried.

• Do not hardcode -j<N> in a Makefile You do not know how many cores does the build machine have. It it must be done, at least use -j$(nproc) (which also doesn't belong in a Makefile).

• CFLAGS overriding is done wrong.

  As I've mentioned in [Bug]: quickjs cross compilation issues #6107, this is issue is often seen in hand-written Makefiles. Please see the following chapter of the GNU Make manual on how CFLAGS overriding should be done: https://ftp.gnu.org/old-gnu/Manuals/make-3.80/html_node/make_125.html#SEC129 It is a minor issue though.

• rebar doesn't echo the build command when builing C/C++

  This leads to cleaner output, but it is worse to debug when the compilation fails. There's a reason why Make echos the build commands.

configure asks for rebar and rebar3. I know little about erlang, but it seems like rebar3 is a successor of rebar. If that's the case, it would make sense to fully transition to rebar3 if possible.

couchdb doesn't have much C code, but I've found errors in a notable portion of its build process. Languate interop can be difficult to get right. I would advise the following:

• Drop all C code which isn't necessary for couchdb. If the C code can be replaced by erlang, do it.

  I'd imagine that since couchdb doesn't have much C code, most of it is there for a purpose. But it's useful to reevaluate it just to be sure.

• Check whether official erlang documentation, rebar or some third party source of documentation could be used for guidance on erlang to C/C++ interop. If for example rebar or some other erlang build tool provides a high-level facility for interop, consider switching to it.

  I assume the C/C++ code is used for interop. If not, disregard this advice.

[nickva]

@meator thank you for the issue and comments. Yeah we definitely have a lot of cruft we accumulated over the years. Some of those fixes/patches may not longer apply and some were just clunky as you pointed out.

For pkg-config, CFLAGS we can probably update them and see how they do in CI. With a wider variety of platform versions now than we did years ago so we could be more confident we hadn't broken anything.

On rebar3. We've had a few tries but we got stuck at Spidermonkey (hopefully that one will be deprecated soon and it will be one less thing to worry about) and some NIF (C module) bits.

Drop all C code which isn't necessary for couchdb. If the C code can be replaced by Erlang, do it.

That's a good goal in general, but we're far from it. Usually C modules are added for performance reasons. Some reasons drop out over time as Erlang gains those optimizations (faster built-in, JIT, etc). But we're still not close to removing all C NIFs at this point. In some cases there are no alternatives but link against a C library (like say libicu for collation).