Unify builds for otp/erts/* targets?

I’d like to build BEAM (at least erts) with a couple of C compiler flags (e.g., -fno-omit-frame-pointer) and want them to be consistently applied to all object files for erts.

However, I noticed that otp/erts has 4 sub targets:

./erts/emulator/Makefile.in
./erts/epmd/src/Makefile.in
./erts/etc/common/Makefile.in
./erts/lib_src/Makefile.in

These targets are built independently with different compiler settings. Is there any benefit of keeping their builds separated? Can we build them as all once with a single Makefile?

2 Likes

What do you mean by consistently applied?

If you set CFLAGS when running configure, all object files should be compiled with the given CFLAGS. Any object file that it does not work on is a bug in the make system.

We keep them separate in order to try to modularize the build system a bit. It could be re-written to a single Makefile, but doing that and making sure that it works on all the different platforms that Erlang should work on is a lot of work and I’m not sure that the end result is better than what we have now.

2 Likes

emulator is built with OMIT_OMIT_FP=yes whenever JIT is enabled regardless of $(TYPE) at otp/erts/emulator/Makefile.in at master · erlang/otp · GitHub

However, lib_src is build with OMIT_OMIT_FP=yes only for $(TYPE) == frmptr at otp/erts/lib_src/Makefile.in at master · erlang/otp · GitHub.

Using CFLAGS=-fno-omit-frame-pointer may ends up using multiple instances of the same compiler flag and also contradicting flag values (e.g., -fno-omit-frame-pointer -fomit-frame-pointer). This is better to be avoided since it will force us to depend on the compiler’s implicit rule to interpret the inconsistent flags (e.g., picking up the last one appearing in the command line).

2 Likes

Ah, now I get what you mean. This is a bug that was introduced when we implemented the JIT, lib_src should also add frame pointers for the JIT.

This is indeed quite messy and could use some cleaning up. I don’t think merging the makefiles will make things simpler though as different executables will need different flags no matter what we do.

3 Likes