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
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.
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.
My configure skills are pretty weak so I need some help fixing this.
cgc
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
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
On Wed, 14 Jun 2006, IOhannes m zmoelnig wrote:
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!
A positive error code means that it failed, only 0 stands for success. Or maybe I just misunderstand what you want to say.
Günter
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
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Quoting geiger geiger@xdv.org:
On Wed, 14 Jun 2006, IOhannes m zmoelnig wrote:
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!
A positive error code means that it failed, only 0 stands for success. Or maybe I just misunderstand what you want to say.
with "positive" i meant the same return code as "true". and not a return value >0.
so the following script will always print "ok" on os-x: <script> if which pd > /dev/null then echo ok else echo ko fi </scritp>
while on linux it will print "ok" if it finds pd and "ko" if it does not find it.
mfg.asdr. IOhannes
-
chris clepper -
geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
zmoelnig＠iem.at