[GEM-dev] configure on OSX

[Hans-Christoph Steiner]

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 at iem.at
> http://lists.puredata.info/listinfo/gem-dev


------------------------------------------------------------------------

News is what people want to keep hidden and everything else is  
publicity.          - Bill Moyers