Only build tbbmalloc[_proxy] if requested

[WardBrian]

Summary

We have a make variable called TBB_LIBRARIES which controls whether tbb is built or if tbbmalloc and tbbmalloc_proxy are as well. This variable is supposed to be set up such that these optional packages are only built on mac (see our docs). However, at the moment, they are always built due to a misconfigured(?) make dependency.

This leads to stan-dev/cmdstan#1218, which is resolved by this PR.

Tests

Side Effects

As far as I can tell, none, but I wouldn't be shocked if we had baked in some accidental assumption about these libraries being available.

Release notes

Fixed a build configuration issue where the optional tbbmalloc and tbbmalloc_proxy libraries were built unconditionally.

Checklist

• Copyright holder: (fill in copyright holder information)

  The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
  - Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
  - Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

• the basic tests are passing

  • unit tests pass (to run, use: ./runTests.py test/unit)
  • header checks pass, (make test-headers)
  • dependencies checks pass, (make test-math-dependencies)
  • docs build, (make doxygen)
  • code passes the built in C++ standards checks (make cpplint)

• the code is written in idiomatic C++ and changes are documented in the doxygen

• the new changes are tested

[WardBrian]

Jenkins seems to be having some unrelated config issues, the first run of this passed all the relevant things to confirm we don't accidentally rely on this

[syclik]

@WardBrian, this PR breaks the build on develop. Can I revert this merge for now?

[syclik]

This is the build failure: https://jenkins.flatironinstitute.org/blue/organizations/jenkins/Stan%2FMath/detail/develop/217/pipeline

[WardBrian]

Went away on re-run

[syclik]

Great! (That sucks that it fails incorrectly at times.)

[WardBrian]

I'd never seen that one before, but there seem to be at least a couple sources of nondeterminism in the math pipeline that I have not been able to pin down

[syclik]

Nondeterministic behavior is tough to pin down, for sure.

Maybe an easy-ish on dev fix is retry on failure? Like 1 retry?

[WardBrian]

I'm not sure if that is something we could automate or not - good question for @serban-nicusor-toptal

[serban-nicusor-toptal]

I think we can just move the step that's failing inside a retry block. stanc3 example
I'll create a PR early tomorrow for Math to retry the headers check.

[WardBrian]

The other thing that sometimes randomly fails is the thread tests sometimes don't build.

If this is due to some sort of runner incompatibility, will the retry pick up the same runner again?

[serban-nicusor-toptal]

I couldn't find anything for sure but I think it will just pick a different executor based on availability. Looks like there's an agent conditional too -> https://www.jenkins.io/doc/pipeline/steps/workflow-basic-steps/#retry-retry-the-body-up-to-n-times
I'll read a bit more about it and then try it out in a PR.