Prompted by this comment.
The scoring of optional flags passed to compilers/interpreters has already been handled here and here. However there is another case of one more level of indirection. Specifically compilers/interpreters for some languages may themselves be built with extra options to enable/disable certain optional features. These options may be passed to the
./configure script run before building the given compiler/interpreter, assuming the common
./configure && make && make install build paradigm.
For example, the bash shell (interpreter for the bash shell language) has quite a few of these options, for example:
- The first is disabled by default, that is we need to pass
./configurescript to enable it in a new bash build.
- The second is enabled by default; that is to access this this feature, then no defaults need to be changed. However, if we need to disable it for some reason, then we need to pass
--disable-net-redirectionsto the configure script.
In the case any of these optional are needed, how should these extra build options be scored?
I've added some answers. With @MartinBüttner's encouragement I've deleted some of these answers to allow more community input and not swing the discussion with my own bias. Having said that, some other suggestions for possible solutions are:
- Only allow bone-stock builds of the compiler/interpreter
- Only allow bone-stock builds of the compiler/interpreter with all optional features turned off (even defaults)
- Allow any compiler/interpreter build options for free
- Assume all optional features turned off (even defaults) and add option length to score for any optional features used (even defaults)
Vote and add your own as you see appropriate. Please don't be shy about downvoting answers you think are no good.