Would this be something you’d like to put on Github? I created an unofficial pure-data group: https://github.com/pure-data https://github.com/pure-data
You’re thinking is right along what Chris and I have been discussing. I have a script I use to build vanilla and the extended libs I need on Udoo (attached) and we’ve been thinking of ways to have a system with links to all the external repos, etc. Anyway, I’ll throw this at you and and bring Chris in since I think he has an alpha set of scripts as well. I think we’re all talking about the same thing ...
-------- Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
From: katja katjavetter@gmail.com To: pddev pd-dev@iem.at Date: March 8, 2015 at 6:52:38 AM EDT Subject: [PD-dev] Makefile.pdlibbuilder and a question about default install paths
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:
- source and rule definitions are together in a single file so it is
a pain to upgrade Makefiles to a new template version
- the template can not handle multiple source files for multiple
class executables
- 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