Forgot to mention most important thing. Before investing much time in a lib's build system, try to locate the upstream source and discuss your ideas with the author or maintainer. This raises the question where upstream sources currently are, that is for another thread.
Katja
On Wed, Dec 16, 2015 at 12:39 AM, katja katjavetter@gmail.com wrote:
On Tue, Dec 15, 2015 at 5:03 PM, Roman Haefeli reduzent@gmail.com wrote:
On Tue, 2015-12-15 at 16:32 +0100, IOhannes m zmoelnig wrote:
On 2015-12-15 16:09, Roman Haefeli wrote:
p.s.: I converted the few externals I care about to Katja's pd-lib-builder Makefile.
please give back.
I'm willing to.
[snip]
I'm open to suggestions and discussions about road maps.
A general roadmap could be that anyone who is in the position (because of interest and capability) to contribute to a build system for a Pd lib forks that library like you have done. When a build system is tested to work well on 'all' platforms, it could proposed to the original library author. For orphaned libraries this may be fuzzy as it leaves your fork with the most up to date code, raising unspoken expectations that you will maintain the rest of the code too. On the other hand, your efforts may give an impulse to others who want to contribute, or maybe a seemingly orphaned library turns out to be not orphaned after all.
Testing is much more work than writing a makefile, as all classes in a lib must be verified to still work on 'all' platforms before a build system can be safely replaced. Your makefile for iemnet has this conditional variable definition:
ifeq ($(uname), MINGW) ldlibs = -lwsock32 endifDid you test it on Windows? The conditional check happens before Makefile.pdlibbuilder (which defines variable 'uname') is included. Issue #7 on https://github.com/pure-data/pd-lib-builder/issues/7 discusses a method which is in a topic branch and waiting to be merged into master. Your findings can be helpful here too.
Thanks, Katja
Roman