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