On Unix, NSPR's build system is based on GNU make. Build options are make variables (such as BUILD_OPT, USE_PTHREADS, etc.) specified either as environment variables or on the gmake command line. Specifying the NSPR make variables appears to be a significant learning obstable to developers of other products that have to build NSPR from the source, e.g., SeaMonkey. To them, the NSPR make variables are yet another build system to learn. They want to be able to just say 'gmake'. Ramiro proposes that nsprpub/config/config.mk include user-specified makefiles (if they exist), in which the build options can be specified and the values of certain make variables can be overriden. The user config and overrides makefiles could be generated by the configure script of the product that uses NSPR. Then, the user could just type 'gmake' in nsprpub. At the beginning of nsprpub/config/config.mk, we include nsprpub/config/my_config.mk, if it exists. The purpose of this makefile is to set build options, which are the input to the NSPR build system. At the end of nsprpub/config/config.mk, we include nsprpub/config/my_overrides.mk, if it exists. The purpose of this makefile is to override the values of certain make variables, which are the output of the NSPR build system. This is a general mechanism for bridging the build system of another product with NSPR's build system. It is not specific to SeaMonkey. Can I check this in?

We use the environment variables NSPR_MY_CONFIG_MK and NSPR_MY_OVERRIDES_MK to specify the names of these two makefiles. If unspecified, they default to nsprpub/config/my_config.mk and nsprpub/config/my_overrides.mk, respectively. /cvsroot/mozilla/nsprpub/config/.cvsignore, revision 3.2 (to ignore my_config.mk and my_overrides.mk) /cvsroot/mozilla/nsprpub/config/config.mk, revision 3.8 Marked the bug fixed.

NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.

this fix is not visible to qa. if you think this bug should be reopened, please do so. will mark as verified.