[L2Ork-dev] Purr Data Build Support Group

Jonathan Wilkes jon.w.wilkes at gmail.com
Thu May 14 23:52:28 EDT 2020

Hi all,

Before GSoC officially kicks off this summer, I'd like to start a
support group for those of us who have come into contact with Purr
Data's build system.

Purr Data's build system is very bad. It causes much pain.

Here are some tips to help you avoid as much pain as possible:

1. Initial build

It appears to me that none of the GSoC projects will require building
all the externals like Gem and friends. This means you can do this in
the toplevel purr-data/ directory to do a quick build:

`make light`

You should get an installer in the toplevel in around 5 minutes. The
installer will include the core, GUI, and a few helper externals for
documentation and a few other things. That saves a lot of time over a
full build.

2. Incremental core builds

There are some nested build files in purr-data/pd/src to build the
core. The usual autoconf files may be found in that directory. If you
already did `make light` in the main repo directory autoconf will have
already done its magic and created a makefile here. That means if you
make changes to any of the core source files and you can do this in


It will then incrementally build a new binary named pd-l2ork which may
be found in purr-data/pd/bin/. (Under Windows the binary may be named
something else, like pd.dll-- can't remember atm.)

You can then copy  that binary to the location of the installed binary
to overwrite it. For example, on my Debian system I can do this:

`sudo cp ~/purr-data/pd/bin/pd-l2ork /usr/bin/pd-l2ork`

Now the next time I run Purr Data I have the core from my incremental build.

Using this method means that when I edit a source file, I can
recompile and be running the new binary in less than 10 seconds.

3. Incremental GUI changes

The GUI files for Purr Data reside in purr-data/pd/nw of the repo

This method for incremental GUI changes is still a bit hacky but it
works. If you look at the top of purr-data/pd/src/s_inter.c you'll
find this:

#define GUIDIR "" /* "/home/user/purr-data/pd/nw" */

Delete the empty string, uncomment the path to nw, and change that
path so it points to purr-data/pd/nw from your working copy of the

Now do an incremental core build as outlined in #2 above and copy the
changed pd-l2ork binary to the relevant location.

Now when you run Purr Data it will use your cloned version of the repo
to load the GUI. This means you can edit a file like
purr-data/pd/nw/pdgui.js, restart Purr Data and immediately see the

In fact, for things like dialogs and css files you can even edit the
files then close and reopen the dialog to see the changes without
restarting Purr Data.

That's about it.

Please feel free to post more tips here if anyone has them. I tend to
keeps my development flow pretty ascetic.

Also, it occurs to me that the dev experience could be improved if
there were a startup flag to specify where to find the nw directory.
That would make incremental GUI builds much more ergonomic (not to
mention consistent across platforms).

If any of you would like to get some experience with incremental core
builds by implementing that startup flag I'll happily accept a merge
request. :)


More information about the L2Ork-dev mailing list