On Jun 14, 2006, at 6:42 AM, IOhannes m zmoelnig wrote:
chris clepper wrote:
I think I might start using configure/make on OSX since I am getting tired of fighting XCode, but autoconf and configure don't completely work. Some of the issues: --with-pd= didn't work for me. I manually added the -I/path to the makefile
the "--with-pd"-argument really expectsw the pd-binary(!) and not the path to where pd lives (therefore it won't find the pd-sources) i'll have to have a look how this is done with other externals.
It doesn't build a bundle. The configure script spits out this: 'checking whether linker accepts "-bundle -bundle_loader no pd in / bin /sbin /usr/bin /usr/sbin"... no'. There's not really any other option besides a bundle for GEM on OSX so that could probably be a fixed setting.
i just checked and noticed that "which pd" (which is used to determine where the pd-executable lives if no "--with-pd" is used) on osx returns something like the following (on stdout instead of stderr) on failure: "no pd in /bin /sbin /usr/bin /usr/sbin" and a positive error code! therefore there is no easy way to detect, whether the "which pd" failed and instead the pd executable is assumed to be "no pd in / bin/ ..." which of course is non-sense. then the linker checks whether it can build a bundle with "no pd in.." and fails.
however i should succeed if you give the full path like "--with-pd=/ path/to/pd/bin/pd.exe" (the .exe suffix is just here to illustrate what i mean)
If this was set to a sensible default, like a relative path (../../pd/ bin/pd) within the standard dev layout (http://puredata.org/docs/ developer/devlayout ), it would save most of us a lot of hassle. Then the --with-pd option could be for special circumstances. I think we all have better things to do that supporting every directory layout under the sun.
$(which pd) doesn't really work well on Mac OS X since most people do not install a command line version, so it doesn't really make sense for most situations.
.hc
The SIMD check finds that the compiler accepts -msse2 on PPC. The check should check for the actual CPU or at least do a uname -s and uname -p like I suggested for the Pd endian checks.
i have no checked in a configure version that uses "uname -m" for this task and which won't test for e.g. "sse2" on ppc unless explicitely asked for with "--enable-sse2". "uname -p" is problematic, since it doesn't return anything useful ("unknown", or an error about an invalid flag) on my linux machines.
My configure skills are pretty weak so I need some help fixing this.
hopefully we can fix it together.
fgma.sdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers