# How to detect whether the build (compiler options) is a production build

**URL:** <https://discourse.julialang.org/t/how-to-detect-whether-the-build-compiler-options-is-a-production-build/113827>\
**Category:** General Usage\
**Tags:** question, testing, performance, coverage, ci\
**Created:** [May 4, 2024, 12:05pm UTC](https://discourse.julialang.org/t/how-to-detect-whether-the-build-compiler-options-is-a-production-build/113827 "2024-05-04T12:05:34Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [May 4, 2024, 12:05pm UTC](https://discourse.julialang.org/t/how-to-detect-whether-the-build-compiler-options-is-a-production-build/113827/1 "2024-05-04T12:05:34Z")

</div>

Enabling code coverage changes how Julia code is compiled and executed. In particular, code coverage may cause allocations in code that would otherwise be constant-folded:

> <https://github.com/JuliaLang/julia/issues/49978>
>
> Found while debugging the failures of \[FieldFlags.jl\](https://github.com/Seeleng…rab/FieldFlags.jl/actions/runs/5104788857/jobs/9175949759#step:6:108) on nightly - the tests run fine on 1.9, haven't yet tried to bisect. Since it's not (yet) through its registration period, you'll have to \`\]add\` the github repo directly for reproducing.
> 
> Either way, the failures are reproducible with 
> 
> \`\`\`
> julia --color=yes --project=. -e 'import Pkg; Pkg.test(;coverage=true)'
> \`\`\`
> 
> but not with 
> 
> \`\`\`
> julia --color=yes --project=. -e 'import Pkg; Pkg.test(;coverage=false)'
> \`\`\`
> 
> which make the tests run through. I'll see if I can minimize the failure a bit more.
> 
> EDIT: For posteriority, a smaller MWE without dependencies:
> 
> \`\`\`julia
> \[sukera@tower ~\]$ julia --code-coverage -q
> julia\> h(x) = iseven(x) ? "string" : 1
> h (generic function with 1 method)
> 
> julia\> g() = h(2)
> g (generic function with 1 method)
> 
> julia\> Base.infer\_effects(g,())
> (+c,!e,+n,+t,+s,+m,+i)
> \`\`\`
> 
> \`\`\`julia
> \[sukera@tower ~\]$ julia -q
> julia\> h(x) = iseven(x) ? "string" : 1
> h (generic function with 1 method)
> 
> julia\> g() = h(2)
> g (generic function with 1 method)
> 
> julia\> Base.infer\_effects(g,())
> (+c,+e,+n,+t,+s,+m,+i)
> \`\`\`

On the other hand, it’s sometimes good to have tests in a package’s testsuite to check whether certain calls allocate or not. It seems these tests need to be disabled while coverage is enabled.

But how to detect whether coverage is enabled?

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [May 5, 2024, 4:46am UTC](https://discourse.julialang.org/t/how-to-detect-whether-the-build-compiler-options-is-a-production-build/113827/2 "2024-05-05T04:46:31Z")

</div>

Taking my question of “how to detect code coverage” literally, the answer is that there’s `Base.JLOptions.code_coverage` (_not_ public). However, I realize that I was asking the wrong question, e.g., what if the user decides to disable compilation, or lower the optimization level; that could presumably cause allocation just like code coverage did. But testing for each compiler option that may result in suboptimal performance isn’t robust, because I could never be sure I covered all the possible options.

A better question to ask might be “how to detect a production build”, because for a production build I can tell with certainty that some calls mustn’t allocate. I’ll change the title.

I guess it’d be fine if there was an additional compiler flag, which would convey whether the intent of the build is “production” or not. I’d also need a public API to query the value of this flag, perhaps a Preferences.jl preference would suffice. Then I could use this in the test suite to enable/disable certain tests. I’ll make an issue for the FR on Github. EDIT: actually, this seems more like it should be a package.

---

<div class="post-metadata">

**Author:** ![kimikage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kimikage/32/14534_2.png) [@kimikage](https://discourse.julialang.org/u/kimikage)\
**Post date:** [May 5, 2024, 6:32am UTC](https://discourse.julialang.org/t/how-to-detect-whether-the-build-compiler-options-is-a-production-build/113827/3 "2024-05-05T06:32:48Z")

</div>

> [@nsajko](#):
>
> whether the intent of the build is “production” or not

By whom is it intended?  
If a “production” build mode is available, users will always expect a “production” build mode as the default.  
Some users want stability over speed in their products. Some users want detailed logging.  
In the end, if how the flags are used is package-dependent, it is something that should be managed by the package.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [May 5, 2024, 6:35am UTC](https://discourse.julialang.org/t/how-to-detect-whether-the-build-compiler-options-is-a-production-build/113827/4 "2024-05-05T06:35:36Z")

</div>

> [@kimikage](#):
>
> By whom is it intended?

By the user, which would most often be CI, in this case, but also might be me if I decide to run the test suite locally.

Anyway, as someone suggested in the other thread, using an environment variable seems like the best approach.