How should we score compiler/interpreter build-time options?

Question

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:

--enable-extended-glob-default
--enable-net-redirections

• The first is disabled by default, that is we need to pass --enable-extended-glob-default to the ./configure script 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-redirections to 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.

Answer 1

I think it's hard to properly define what "default" means in a few cases. Take php for example: it has a pretty huge default library, but most of it you can only access if the appropriate module is built. The list of "default" modules is usually not set in stone, different distros think differently on what should be part of php by default and what not: should we only limit it to the language that was meant by the langauge maintainers, if that would mean most common compiled implementations (e.g. actual binaries you get from the distros) are out of the question? Or should we limit to language maintainer defaults + anything that it is in at least one usable binary that you can find? What about linux distros, like gentoo, where you can fine tune what gets built?

I think it is much easier to just allow any of the compiler flags for free. A compiler / interpreter built with different flags, is still just another compiler / interpreter (we can probably argue about whether the actual binary that was built is "existing" before or after the challenge was posted, and whether a solution using some non standard flags is using a loophole or not, but I'd say if the source code is there before the challenge, then it's okay).

Is it something that could potentially be abused? Yes, as @Doorknob said, one would just create a weird language that only has compiler flags (I guess they would be in the family of languages). But I think the community is good enough to downvote answers like this, while in no way limiting actual creative use for language features that are there, but just not widely used (like the one that started this discussion in the first place).

Actually: We could just use the definition of the languages to create a rule around compiler flags: if the compiler flags make the language an language, then they count as 1 byte/character per byte/character in the flag. Otherwise they are free. This definition would hopefully discourage most of the loophole usage, while still retaining the creative approach. This would also make it a properly defined rule around compiler flags (for anyone who dislikes rules that are not set in stone)

Answer 2

Note this is the same as this answer with one important distinction in scoring calculation.

---

Anything that uses the default compiler/interpreter build should not incur any extra scoring. That is, since the --enable-net-redirections bash build option is enabled by default, it does not need to be passed, and should not incur any extra scoring.

However for features that are not enabled by default such as --enable-extended-glob-default for bash, then if you are using a build of bash with this feature enabled at build time, some extra score should be added.

30 extra points for --enable-extended-glob-default seems like a steep penalty. Instead, each extra option enabled will incur 1 extra point.

Answer 3

Anything that uses the default compiler/interpreter build should not incur any extra scoring. That is, since the --enable-net-redirections bash build option is enabled by default, it does not need to be passed, and should not incur any extra scoring.

However for features that are not enabled by default such as --enable-extended-glob-default for bash, then if you are using a build of bash with this feature enabled at build time, then the length of the command-line option should be added to your score - in this case 30 bytes.