sleef: Also build inline headers

[armanbilge]

As described in https://sleef.org/compile.xhtml#inline.

This generates additional header files (rather than changing the standard ones). So, IMHO I see no reason not to enable it, since they can simply be ignored by users who don't need them. I assume this option disabled by default because it increases the build time.

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[armanbilge]

I don't think the CI failures are related to my change, but I could be mistaken. I'm not sure if this formula supports ARM?

The last PR for sleef appeared to pass CI, but it didn't run any tests on ARM:

• sleef 3.5.1 #61178

[carlocab]

Why aren't the inline headers built by default?

The last PR for sleef appeared to pass CI, but it didn't run any tests on ARM:

• sleef 3.5.1 #61178

That's true, but that PR was made in September last year. ARM macOS was released in November.

[armanbilge]

Why aren't the inline headers built by default?

I don't really have a good answer for this. This is the documentation I can find regarding this feature:
https://sleef.org/compile.xhtml#inline
https://sleef.org/additional.xhtml#inline
My best guess is that it makes the build take longer, so it is disabled by default. These additional header files would not interfere at all with ordinary use of the library.

That's true, but that PR was made in September last year. ARM macOS was released in November.

Gotcha. So, what happens if this library doesn't support ARM?

[carlocab]

We should find out why the developers don't enable this by default -- they probably have a good reason for it. It doesn't seem like this should add too much extra compilation time.

As for ARM, we can ignore the build failure for now, but it would be good to report this upstream so that they're aware of the incompatibility (if they're not already).

[armanbilge]

We should find out why the developers don't enable this by default -- they probably have a good reason for it. It doesn't seem like this should add too much extra compilation time.

Actually, I think that is exactly the reason. See: shibatch/sleef#283 (comment)

Yes, running time in CI is increased.
If that is a problem, we can just turn off generation.

---

As for ARM, we can ignore the build failure for now, but it would be good to report this upstream so that they're aware of the incompatibility (if they're not already).

There is this open issue:

• Cannot build on Apple M1 shibatch/sleef#425

Does this address your concerns?

[carlocab]

Sounds good to me. Thanks for your contribution, @armanbilge!

[carlocab]

Incidentally, the error reported at shibatch/sleef#425 is slightly different, but I've posted there with the errors we encountered.

[BrewTestBot]

@carlocab has triggered a merge.