The CHPL_DEVELOPER environment variable¶
It is strongly recommended that all Chapel development work be done
CHPL_DEVELOPER set by default (to any non-empty value,
true). In particular, all code that is committed should be
able to be built with
CHPL_DEVELOPER is set; otherwise, that code is
considered to break the build.
CHPL_DEVELOPER has a number of impacts on how things behave,
most of which are set up to serve the typical developer as best
possible. In particular:
When building the compiler and runtime, it causes:
debugging to be turned on
computation of dependences to be turned on
optimizations to be turned off
a number of warnings to be turned on with the goal of making our code as portable and bulletproof as possible
make cleanon the compiler, it causes intermediate files generated by compiling the
chapel.lexfiles to be deleted. We don’t delete these for end-users in case they don’t have flex/bison installed.
Performs sanity checks while building the compiler like checking to see whether we’ve accidentally
#includedany old-style C headers rather than their snazzy new C++ equivalents. (That may currently be the only one; others have existed in the past).
Builds an emacs TAGS and BROWSE file for the compiler and a TAGS file for the runtime.
--develby default when invoking the
chplcompiler. This in turn has the following effects:
hiddendeveloper flags when invoking
chpl --help(these flags are equally available to developers and non-developers).
Causes internal errors to not be obfuscated as they are for an end-user.
Causes error messages printed by the compiler to have the compiler filename: line# to be postfixed to the error message itself.
Permits filename: line# information that is printed for execution-time errors in the user code to refer to internal modules rather than trying to hide this from the end-user by always pointing to the most recent call in their code.
Causes TAGS files to be generated when compiling with the
--savecflag to index the generated code in addition to the runtime sources.
--cc-warningsby default. This generates warnings in the generated C code (with the intention that we get rid of them).
--no-cpp-linesby default. This squashes the generation of C preprocessor #line directives in the generated code (which are used for end-users to fool tools into reporting things in terms of Chapel source line numbers).
Causes internal modules to be printed out when compiling with the
Prints a greater amount of instantiation information when function resolution is printing candidate functions in the case of an error (?).
--report-optimized-onflag to describe optimizations in internal and standard modules in addition to user modules.
Prints out a 4-point version number even if the revision number is 0 (indicating an official release)
--develcan always be invoked manually on the compiler instead of setting the environment variable; similarly,
--no-develcan be used to override the default implied by the presence of the environment variable.
start_testscript will always unset
CHPL_DEVELOPERto ensure that the testing system is running from an end-user perspective and not from a developer perspective.
nightlyscript used to run cron jobs does not set
CHPL_DEVELOPER. Instead, it sets
OPTIMIZE=1when calling make.