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)
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