[PD-dev] Pd-dev Digest, Vol 120, Issue 1

[Dan Wilcox]

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 at gmail.com>
> To: pddev <pd-dev at 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:
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150308/6c21c1ae/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_pd
Type: application/octet-stream
Size: 2752 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150308/6c21c1ae/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150308/6c21c1ae/attachment-0001.html>