Hello,
Currently I am working on a one-size-fits-all build method for Pd libs. It is meant to take the template Makefile concept to a next level. The template is a great help for building Pd libs but it has a few limitations:
1. source and rule definitions are together in a single file so it is a pain to upgrade Makefiles to a new template version
2. the template can not handle multiple source files for multiple class executables
3. implicit dependencies (headers) aren't checked
Makefile.pdlibbuilder overcomes these limitations. It functions as an include in a Makefile which defines sources for classes. For non-clean build of target all, Makefile.dependencies is generated. A (re)build of individual classes can be forced alternatively.
Makefile.pdlibbuilder is in an early stage of development. I've spent much time sorting out the best approach for multiple-source-per-executable procedures. This is working fine now. By way of test I used the method to compile all tilde classes in cyclone, which are all multiple-source. It worked right away without a single gcc error. This is promising enough for me to continue the effort.
My aim is to make it a user-friendly method for building individual libs against any of the 'Pd-flavours', while at the same time integrating with Pd-extended's unified build system. There's aspects I can't figure out on my own, some due to my lack of knowledge, some because they need discussion to make decisions.
My first issue is with the default install path for a Pd lib. In the template Makefile it's definition boils down to /usr/local/lib/pd-externals/, except for OSX where it is ~/Library/Pd. The path is overruled by Pd-extended's central Makefile, but when building an isolated lib you get this default (which you can eventually overrule yourself). For one thing, I'm not fond of Makefiles installing stuff deep in a file system, so I would consider issuing a warning message or prompt for such a case. Apart from that, the question is to which extent the default makes sense at all. I found this overview of standard search paths for Pd externals:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
Are these search paths valid in 'all Pd flavours' (vanilla, extended, L2Ork)?
By the way I don't want to clutter Pd-dev list with attachments but if anyone is interested I'd be happy to send Makefile.pdlibbuilder in it's current pre-pre-alpha state.
Katja
On 03/08/2015 11:52 AM, katja wrote:
- the template can not handle multiple source files for multiple
class executables
i might have missed that, but: what the current template Makefile can handle (and what yours should be able to handle as well), is the use of "in-situ" libraries for shared code, to avoid code-duplication (in the compiled binaries).
gfdsr IOhannes
On 03/08/2015 11:52 AM, katja wrote:
By the way I don't want to clutter Pd-dev list with attachments but if anyone is interested I'd be happy to send Makefile.pdlibbuilder in it's current pre-pre-alpha state.
it would probably more adequate to publish the code somewhere (e.g. github), where people can fetch the most current version (and contribute back). sharing a fast-moving target via email is a nightmare.
gfmdsar IOhannes
Hi Katja,
katja schrieb am 08.03.2015 11:52:
Currently I am working on a one-size-fits-all build method for Pd libs. It is meant to take the template Makefile concept to a next level.
By the way I don't want to clutter Pd-dev list with attachments but if anyone is interested I'd be happy to send Makefile.pdlibbuilder in it's current pre-pre-alpha state.
please send it to me, I would like to test it for PuREST JSON, as I am already using a custom Makefile based on the template, and still not happy with it.
Thanks, Thomas