[A preliminary remark: We have to improve FreeType's terminology. For example, in `ftconfig.h` there is some talk about 'build directory'. Users might assume that this refers to the directory where compilation puts its object files. However, this is not the case. I will probably do `s/BUILD_DIR/PLATFORM_DIR/` for clarity and update the documentation accordingly.]
> We host custom/generated ftoption.h and ftconfig.h in either > BUILD_DIR or DEVEL_DIR. This is not correct. In a normal build with srcdir != builddir and srcdir read-only, we either have the unmodified `ftoption.h` and `ftconfig.h` files (the latter is only of interest if none of the platforms in the `builds` directory are sufficient, which is rather unlikely today) in `SRC_DIR`, or we have user-modified files in `OBJ_DIR`. A user-defined `BUILD_DIR` comes only into play if you need to support exotic operating systems not covered with the stuff in the `builds` directory. `DEVEL_DIR` is just a swap-in to quickly replace `ftoption.h` for development builds; it is set by `make devel` (this target exists only for pure GNU make builds; meson and cmake don't support it). In summary, we have the following order for include files. $(DEVEL_DIR) (set by `make devel`, defaulting to being undefined) $(BUILD_DIR) (set by the various `detect.mk` files for a pure GNU make build, hard-coded otherwise) $(TOP_DIR)/include You can find exactly this in `freetype.mk`. `ftoption.h` is handled separately by FTOPTION_H, which in turn is configured by pure GNU make builds and hard-coded otherwise. > Only one of them is always defined but not both. Why should > ftmodule.h be different? They are not different. If a user wants to restrict the modules, the file `modules.cfg` should be adjusted and put into `OBJ_DIR`. A corresponding `ftmodule.h` file will then be automatically created by make (and meson, but not cmake AFAICS). > This should work but slightly later in toplevel.mk. > > ifdef DEVEL_BUILD > FTMODULE_H ?= $(DEVEL_DIR)/ftmodule.h > else > FTMODULE_H ?=$(BUILD_DIR)/ftmodule.h > endif Such an approach is not necessary, I think. > We do not Your e-mail ends mid-sentence... Werner