Re: [fluid-dev] Again on "Compile time constant lookup tables"

[Tom M.]

> what you think about using an external tool for compiling the const tables, 
> like Python. [...] The tool will be searched by cmake with REQUIRED option

I don't want to compel people to require yet another build dependency. While we 
have very good reasons to make glib a dependency, making e.g. python a 
dependency seems questionable as the current runtime solution works flawlessly 
for 99% of all users.

Carlo initially brought this idea up, in order to allow fluidsynth to run on 
very ressource limited hardware. I still support this and tried to find a 
solution that allows potentially more users to benefit from this... it turned 
out a little more complicated than I thought.

Personally I prefer the current C90 compliant solution that relies on the 
preprocessor (#423). The only significant drawback of this approach I see is 
that it does not allow to make *all* lookup tables "constexpr". Namely all 
tables that use pow(). As for pow() one needs a recursion, which the 
preprocessor is lacking.

If this is a problem (dont know, pls. tell me), I would vote for falling back 
to Marcus proposal and VC those autogenerated files generated by an external 
(upstream exclusive) tool. Yes one shouldn't do that, but watching the prior 
github discussion, we don't have any better alternatives currently; and yes, 
the lookup tables are (partly) given by the sf2 spec and very unlikely to ever 
receive a different implementation (i.e. values). In this case I'd vote for 
using Carlo's C tool... not python.

Tom