nickva commented on issue #6107: URL: https://github.com/apache/couchdb/issues/6107#issuecomment-5573841258
Thanks for taking a look at CouchDB @meator! The [src/couch_quickjs/quickjs/Makefile](https://github.com/apache/couchdb/blob/78395184b02cdc9573c3536ec72721fb353d5442/src/couch_quickjs/quickjs/Makefile) is vendored from upstream https://github.com/bellard/quickjs/blob/master/Makefile > Right of the bat, the fact that couchdb doesn't use any higher level well established build system is an issue. The fact that the project uses a hand written configure script and an elaborate Makefile structure do not necessarily have to mean that the build system is less capable than CMake for example, but my experience shows that there is a very strong corelation between such endevaurs and configure/build errors + poor or nonexistant support for systems not exactly matching the developer's build environment. That's fair take. Our system is a configure script + a makefile at the top level. Then since most of our applications are Erlang they use rebar 2, an erlang-specific build tool https://github.com/rebar/rebar/wiki/Getting-started. Rebar knows how to recursively build all the Erlang applications on both Windows and Unix-like systems. Some Erlang applications use C modules or C executable (like the QuickJS one you found). In that case rebar2 with some config files knows how to execute either a local Makefile or any other command. Here is a simple example: https://github.com/apache/couchdb/blob/main/src/exxhash/rebar.config. The QuickJS example is a bit more complex as it involves executing some pre-compilation / post-compilation steps: https://github.com/apache/couchdb/blob/main/src/couch_quickjs/rebar.config.script. While the main executable doesn't use that Makefile you found the pre commands do. Typically the way we build for various os/hardware combinations is via a bunch CI build docker images with Erlang, C compilers and everything build natively on that combination. We had never tried to cross-compile CouchDB from what I remember. It's just not a configuration or build mode we even thought of so unsurprisingly there are lot of corner cases and oddness that would make it tricky. We've been talking about migrating to rebar3 and now there is even a rebar4 erlang project brewing so we may want to wait. Another alternative is https://erlang.mk based on just makefiles (excluding rebar) and of course there is CMake, ninja and others. But our system has proven is good enough for now for the release / build modes we support currently that's why there is not much of a push to revamp it. Perhaps if there is a small patch or a few extra improves to support cross-compilation it would be nice to add those (with a CI step to ensure is stays working). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
