[L2Ork-dev] GSOC Query

[Jonathan Wilkes]

Comments below:

On Mon, Apr 18, 2022 at 7:56 PM Adelaide Zhang <adelaidemzhang at gmail.com> wrote:
>
> Unfortunately I wasn’t able to find anything in the vanilla pd mailing list regarding the errors I got, or specifically related to compiling on the M1 chip. After taking another look I suspect the issue will not be as easily resolved as I hoped, particularly as I’m not super familiar with build systems (I’ve used them but never written one, although I am familiar with bash scripting).

I'm unfamiliar with the architecture. Rankly speculating about it, I'd
look first at any of the places where Pd's codebase strays from
well-defined C. For example, Purr Data used to invoke some method
calls using the wrong number of arguments. That prevented the web
assembly port from working. In fact, we still don't use the correct
function signatures in that part of the code (and aside from an
enormous union, I'm not sure if that can even be fixed at this point).

>
> I would certainly be willing to delve deeper into the process as part of  the “monstrously complex build system” idea, however I wonder if you have any pointers regarding how thorough of proposal is expected, especially given the deadline tomorrow.
>
> As a rough outline:
>
> (pre- coding period) Thoroughly familiarize myself with Makefiles and relevant compilers

Sounds doable.

> Develop an understanding of how the current build system works (any dependencies, structure of calls)

Also worth doing. But beware-- there are multiple recursive makefile
calls, a hand-scrawled bash script, some dead code paths, and some
hacks to package up all the needed dependencies for both Windows and
OSX.

> Make necessary modifications in order to build on M1 architecture (maybe optional, if virtualization is possible and another platform should be prioritized)

Note that there is a makefile for building the core in
purr-data/pd/src. So it is certainly possible to make modifications
there for a new architecture without needing to touch the rest of the
sprawling build system. (You may need to touch the rest of the build
system to make sure all externals build correctly, too, but that can
come later.)

> Create plan for how an “ideal” system would look

Might be better to try to figure out the *minimum* amount of work to
make the system a bit less of a nightmare.

> Incrementally streamline current system into fewer files based on plan

That sounds like a plan. One thing that may help is figuring out what
tests or revisions we need to do to ensure that a successful build is
*actually* successful. If an external fails to build, or a dependency
for an external is missing, I'd much rather it break the build process
rather than hearing about it from a user after a release. :)

>
>
> The other option might be for me to attempt to work with a virtual machine or Docker instead, and potentially aim for a different project idea.

That's also a possibility. It just depends on which project you are
interested in.

Best,
Jonathan

>
> Let me know what your thoughts are on the matter, or if you have any further suggestions. Thank you!
>
>
> On Apr 18, 2022, at 1:26 PM, Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>
> On Mon, Apr 18, 2022 at 1:55 AM Adelaide Zhang <adelaidemzhang at gmail.com> wrote:
>
>
> Hello,
>
> I recently found out about the GSOC program, and I see that the deadline is very close—I was wondering if it’s not too late to submit an application.I am a current MSCS grad student at NYU with a background in theatrical audio. I very much enjoyed using Max in the past and would love to be able to get involved with its open source sibling.
>
>
> Definitely not too late. Please do put together an application, I'll
> try to help today if I can.
>
>
> I do have a couple of questions—I ran into some make issues when building from the source code (though the pre-compiled app works fine), and I wonder if it’s possibly because I’m working on an Apple Silicon Mac. The only reference I’ve found to the issue on the mailing list is from a year ago here: http://disis.music.vt.edu/pipermail/l2ork-dev/2021-April/003744.html. One of the errors I get is “clang: error: the clang compiler does not support '-mcpu=7450”, but I can provide the rest of the build output if needed.
>
>
> I seem to remember someone mentioning the new Apple chips on the Pure
> Data vanilla list. Perhaps search there to see if anyone made progress
> on it:
>
> https://lists.puredata.info/pipermail/pd-list/
>
>
> If the chip is the issue, is there already a solution for this, or would creating build compatibility with M1 be enough of a basis for a project idea? If it wouldn’t be enough on its own, would it be possible to combine that with a different medium-sized project? I’d be particularly interested in the Vintage Platform Audio Emulation Library and Data Over Audio Messaging ideas.
>
>
> That would definitely be possible. There's also the project to save us
> from our monstrous build system, but that may be too large for a
> medium-sized project.
>
> Best,
> Jonathan
>
>
> Please let me know how best to proceed, or if you need any more info from me!
>
> Thank you,
> Adelaide
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev