make the path to pd-lib-builder configurable

[umlaeute]

when packaging the latest release for @residuum's PuRestJson for Debian i noticed a slight problem with the proposed workflow of the Makefile.pdlibbuilder, as examplified in this helloworld project:

• people use git-submodules to "include" the pd-lib-builder repository at a fixed path (following the helloworld, this is often pd-lib-builder/)
• they include the makefile via include pd-lib-builder/Makefile.pdlibbuilder
• they release software by creating tags and pushing them to (e.g.) github.

there is one catch to this setup:

• when downloading the release tarball, the git-submodules are missing.

this basically makes the release-tarballs unusable (well, kind-of).

in some of my personal projects I use local copies of the Makefile.pdlibbuilder: while this fixes the problem, I can see that this is not very practical (for updating the pd-lib-builder Makefile).

I have therefore started to use both a git-submodule and a local copy of the pd-lib-builder Makefile (e.g. iemnet), where the local copy is only a fallback, if the submodule is missing.
I understand that people might still consider this an overkill though.

[umlaeute]

considering my two ideas in the original report impractical, here's a simple proposal:

• use a variable for the actual position of the pd-lib-builder makefile:

PDLIBBUILDER_DIR=pd-lib-builder/
include $(PDLIBBUILDER_DIR)/Makefile.pdlibbuilder

this would allow people who do not check out the git-submodules (e.g. because they download the release tarballs) but who have a local copy of the Makefile.pdlibbuilder to use that instead:

make PDLIBBUILDER_DIR=/usr/share/pd-tools/pd-lib-builder

[danomatika]

Yeah, this is a common problem with Github. The releases simple do not include the submodules. We've run into this problem with new libpd users: https://github.com/libpd/libpd#getting-libpd

It is possible to roll your own release file and manually addd it to the GH releases page, but of course, most people are probably unaware of this problem.

[umlaeute]

also, taring up your own release file (properly) and uploading it is significantly more work than just git tag && git push.

[electrickery]

PDLIBBUILDER_DIR=pd-lib-builder/
include $(PDLIBBUILDER_DIR)/Makefile.pdlibbuilder

This could be as well part of the main Makefile (which includes Makefile.pdlibbuilder).

For the binary packages I distribute, I copy the used version of Makefile.pdlibbuilder in to the package (in the Sources.tgz). This is know to work. If someone wants to compile for a new platform or with more modern settings, she/he should be prepared for possible version incompatibilities.

Hopefully, creating Source packages will be part of Makefile.pd-lib-builder some time in the future. Then between deken and Makefile.pd-lib-builder the packaging and releasing is almost fully automated. Maybe more than we should want; the build server at http://autobuild.puredata.info is still creating daily (but empty) directories for pd-extended builds.

[umlaeute]

This could be as well part of the main Makefile (which includes Makefile.pdlibbuilder).

yes, that is what i wanted to say.
my point is, that *this helloworld repository should use this pattern, as this is the reference project for pd-lib-builder.

i'll submit a PR...

[katjav]

The proposed variable is also useful for testing with different pd-lib-builder versions in case of regression bugs and such.

[umlaeute]

while i haven't thought of that, it is a good point.

in this spirit i suggest that even if this project switched to a local makefile (as suggested #4), it should still use the variable, as in:

PDLIBBUILDER_DIR=./
include $(PDLIBBUILDER_DIR)Makefile.pdlibbuilder