[L2Ork-dev] Purr Data 2.6.0

[Jonathan Wilkes]

On Wed, Sep 26, 2018 at 6:13 AM Albert Graef <aggraef at gmail.com> wrote:
>
> On Wed, Sep 26, 2018 at 9:48 AM Albert Graef <aggraef at gmail.com> wrote:
>>
>> On Wed, Sep 26, 2018 at 3:00 AM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>>
>>> >> CFLAGS="-DPD_FLOATSIZE=64" make light
>>>
>>> I'm not sure how it would override anything it shouldn't.
>>
>>
>> Well, CFLAGS is set up in meticulous detail in externals/Makefile, but looking at the build logs I'm still not seeing a CFLAGS="-DPD_FLOATSIZE=64" in the environment being picked up *anywhere* by the externals during a regular build. Presumably that's because in tar_em_up.sh, we're running `make install` right away without doing a `make` first, and the install targets in externals/Makefile don't pass on CFLAGS to submakes anyway.
>
>
> That's not really true. I overlooked that `all` is in the prerequisites of the `install` target after all. And in fact all those options in the CFLAGS of externals/Makefile *are* needed, otherwise lots of stuff doesn't compile any more.
>
> But I finally found a way to pass the extra options reliably and without messing with any of the existing options. Whether CFLAGS is actually heeded by all the external targets is another matter; I sure hope so, but we can only be certain if someone (not me) sifts through the build log (and possibly some of the Makefiles for targets where the buildlog doesn't reveal this). But at least I have a full double precision build working now. I had to put autotune and smlib on the blacklist for double precision, though; apparently these haven't been ported yet. I also still need to check the double precision build of Gem.

Sounds good.

As for the externals-- the complicated case arises if an external
library does bit twiddling that assumes a single-precision float. For
GSoC
we used the union trick for that which is demonstrated by the
PD_BIGORSMALL macro.

Other times it can be just changing float to t_float, although we
still want to eyeball and earball that to make sure there wasn't some
trick that depended on single-precision.

Also-- that union trick is not standard C-- gcc and clang support it
but AFAICT C99 doesn't require the ability to read the other member
after writing the first member. (Plus if the members aren't aligned
and you read/shift past the bounds you are in trouble.)

Someone on Hacker News made a big deal about using memcpy instead of
the union trick under the assumption that "any sane compiler will
optimize out the system call." But then we'd be depending on
optimization behavior, plus inserting a system call in the realtime
graph when
doing a debug build.

For the GSoC project, everything in pd/extra was ported, plus freeverb~.

-Jonathan

>
> I'm currently testing this on Linux, expect a pull request later today or tomorrow.
>
> Albert
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email:  aggraef at gmail.com
> WWW:    https://plus.google.com/+AlbertGraef
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev