-------- Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 14, 2015, at 4:00 AM, pd-dev-request@lists.iem.at wrote:
From: Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> Subject: [PD-dev] building on OS X Date: December 14, 2015 at 1:53:10 AM MST To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at
- Do I need XCode? (and thus an Apple-ID?)
Yes, you need Xcode. It has the compiler & build chain you need. Open source projects generally compile just fine from the commandline. You do not need to use Xcode itself for building Pd.
You also don’t need to install Xcode form the App Store. If you have an Apple ID (or can borrow someone’s) you can download the current & beta versions of Xcode from the Apple Developer site https://developer.apple.com/ and just install it yourself.
- How do I install all other necessary tools (git, etc.)? I heard about
homebrew, fink, macports…
Use Homebrew. It’s great: http://brew.sh http://brew.sh/
- Once things are set up, is it feasible to have completely CLI based
workflow?
Yes.
Hey Dan
Thanks a lot for the insight. With your few hints the process turned to be easier than I initially thought. I got a few externals compiled and uploaded to deken (no ppc, though, just fat as in i386 and x86_64). netpd runs now easily with Pd-vanilla on OS X. Great :-)
Roman
p.s.: I converted the few externals I care about to Katja's pd-lib-builder Makefile. I never felt quite comfortable with building binaries from source as it often lead to issues I lacked the knowledge to properly deal with, thus I was conditioned to connect building with pain. I must say the switch was almost pain-free process and it worked on five different architectures nearly out-of-the-box. The build system has a level of abstraction I believe I can still understand. Katja, I think you did great. I'm a happy and thankful user :-)
On Mon, 2015-12-14 at 12:23 -0700, Dan Wilcox wrote:
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Dec 14, 2015, at 4:00 AM, pd-dev-request@lists.iem.at wrote:
From: Roman Haefeli reduzent@gmail.com
Subject: [PD-dev] building on OS X
Date: December 14, 2015 at 1:53:10 AM MST
To: pd-dev@lists.iem.at
- Do I need XCode? (and thus an Apple-ID?)
Yes, you need Xcode. It has the compiler & build chain you need. Open source projects generally compile just fine from the commandline. You do not need to use Xcode itself for building Pd.
You also don’t need to install Xcode form the App Store. If you have an Apple ID (or can borrow someone’s) you can download the current & beta versions of Xcode from the Apple Developer site and just install it yourself.
- How do I install all other necessary tools (git, etc.)? I heard
about homebrew, fink, macports…
Use Homebrew. It’s great: http://brew.sh
- Once things are set up, is it feasible to have completely CLI
based workflow?
Yes.
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. the biggest problem with deken right now as i see it, is that it makes it super easy to upload some totally unreproducible foo. there is a feature-request [1] to push sourceful uploads, but nothing has been implemented yet.
fgmasdr IOhannes
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.
the biggest problem with deken right now as i see it, is that it makes it super easy to upload some totally unreproducible foo.
I hear you. The ones I cloned from the read-only git repo I'm maintaining here:
https://github.com/reduzent/pd-ggee https://github.com/reduzent/pd-iemnet https://github.com/reduzent/pd-moocow (for readdir) https://github.com/reduzent/pd-mrpeach (for binfile, osc, slip)
Each has an upstream branch with the state from the original repo and a master branch where I'm working in. I'm happy to adapt my workflow to whatever collaboration suits best. Also, I could move the repositories under the pure-data umbrella. I simply felt not comfortable enough to put my half-baked stuff there.
As you see, I ripped the parts out I'm interested in, but I'd be happy to create similar builds for the other mrpeach and moocow externals, too. Right now, it is at an intermediate stage.
I'm open to suggestions and discussions about road maps.
Roman
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 endif
Did 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
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
On Wed, 2015-12-16 at 13:09 +0100, katja wrote:
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.
This assumes that I do have some idea about how things should be done and probably also that my idea would suit everybody.
In turns out I have to work on things first before getting an idea, especially when it comes to build systems. As I see it, I'm trying out stuff and I put it on github so that the process is comprehensible. This does not necessarily implicate any opinion of mine the upstream author should adapt their build system to mine. My goals might be totally different from theirs.
My goal is to make some externals available through deken. I achieve this by building those externals myself. It turned out that autotools gave me head-aches, especially when cross-compiling and I need less time to write a pd-lib-builder Makefile than to figure out how to build with autotools/mingw-w64. I figured out that if I plan to maintain those builds also in the future, the process needs to be streamlined and I need to unify as much as possible the way I build for different platforms but also how I build different externals. At this point, I came to the conclusion the most sustainable way for _me_ is to turn what I maintain to pd-lib-builder.
I care about having some externals in deken. The upstream author might care, too, or doesn't. I don't care so much whether they care. If externals are not available, I try to make them available. If the upstream author decides to put their externals to deken themselves, I'm happy to give them back the maintenance of the deken builds.
For me, the switch from Pd-extended to deken, from svn to git is more than a technical shift. It's a shift from monoculture to a decentralized culture, from asking to doing, from hesitating to trying, from discussing to implementing, from stepping on each others toes to dancing together at the same party. Yes, it is less organized and harder to get an overview of, but the advantages of the decentralized culture outbalance the disadvantages by at least an order of magnitude.
And no, I think I won't discuss my ideas with upstream.. :-)
Roman
On Thu, 2015-12-17 at 11:22 +0100, Roman Haefeli wrote:
And no, I think I won't discuss my ideas with upstream.. :-)
That sounds much harsher than I intended it to be. I mean I don't see the point of approaching upstream pro-actively with regard to what I said about the culture established by git/deken. Of course, I'm willing to discuss anything if the participating parties feels like it.
Roman
On Thu, Dec 17, 2015 at 1:03 PM, Roman Haefeli reduzent@gmail.com wrote:
On Thu, 2015-12-17 at 11:22 +0100, Roman Haefeli wrote:
And no, I think I won't discuss my ideas with upstream.. :-)
That sounds much harsher than I intended it to be. I mean I don't see the point of approaching upstream pro-actively with regard to what I said about the culture established by git/deken. Of course, I'm willing to discuss anything if the participating parties feels like it.
Roman
I mentioned it also because it can save you both a lot of time. Writing makefiles for Makefile.plibbuilder is very easy indeed, but understanding what the existing build system intends to build exactly is sometimes much harder, is what I've found.
Katja
On Mit, 2015-12-16 at 00:39 +0100, katja wrote:
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.
Yes.
Your makefile for iemnet has this conditional variable definition:
ifeq ($(uname), MINGW) ldlibs = -lwsock32 endif
Frankly, I was wondering about that, too. I'm looking for the proper way to set certain flags only for certain platforms.
Did you test it on Windows?
Building works with mingw-w64 on Linux. I haven't tested if it works on Windows. I think I have thoroughly tested the resulting binaries.
The conditional check happens before Makefile.pdlibbuilder (which defines variable 'uname') is included.
Without that clause, building fails on mingw-w64. Without the conditional, it breaks other platforms. I can't tell you why, but it works. I'm open for suggestions about how to do this in a cleaner way.
Roman
-
Dan Wilcox -
IOhannes m zmoelnig -
katja -
Roman Haefeli