[GEM-dev] FYI: auto-build Gem on OSX Fink libs

[Hans-Christoph Steiner]

On Sep 29, 2006, at 5:52 AM, zmoelnig at iem.at wrote:

> Quoting Hans-Christoph Steiner <hans at eds.org>:
>
>>
>> FYI, the current Gem auto-build on Mac OS X is linking against  
>> these  Fink libs:
>>
>>         libdv.4.dylib
>>         libmpeg.1.dylib
>>         libquicktime.0.dylib
>>         libjpeg.62.dylib
>>
>> For some reason, I think this is wrong.  This is the current ./  
>> configure:
>
> well, it is not entirely wrong...if these libraries are installed  
> then configure will detect them and use them...
>
> the problem is, that this makes Gem not very fit for distribution  
> (the more dynamic libraries you have to manually install, the  
> worse) (but i don't tell you nothing new here)
>
> apart from that, it shouldn't change much in the behaviour of Gem,  
> and if it did, it should be for good.

Actually, I've got it scripted as part of the Pd-extended build  
system that it automatically finds and includes any Fink libs that  
are needed, so that's not a problem.  This Gem build does work, its  
just that you guys mentioned that on Mac OS X, Gem should use Apple  
QuickTime, not libquicktime.

>> cd $(gem_src)/src && ./configure --without-ImageMagick --with-pd=$  
>> (pd_src)
>
> in order to manually disable the use of these libraries would be:
> ./configure --without-jpeg --without-ImageMagick --without-ieee1394  
> --without-mpeg --without-libquicktime --without-lqt --with-pd=$  
> (pd_src)
>
> (note: i just write this line from memory, so it is not tested at  
> all).
>
>
> i am really no big fan of automatically disabling all this  
> libraries on osx, since it would make the configure.ac harder to  
> maintain (it's already BIG), and people might want to use it (for  
> whatever reasons).
>
>
> so basically i think: configure (without arguments) should create a  
> build that works on the machine where configure was run. it is not  
> the task of a plain configure to create a package that is  
> distributable for a lot of machines.

I agree, ./configure && make should work everywhere.  But  
generally, ./configure is good at sorting out finding which lib to use.

> if you need this, you will have to provide arguments to configure  
> (disabling the use stuff that is installed on the machine for other  
> reasons, enabling stuff that is not installed on the build-machine  
> but on the target machines...)

I guess the only situation I can see here is Quicktime.  Would it be  
difficult to ignore libquicktime if Apple QuickTime is detected?  The  
GEM_CHECK_FRAMEWORK is already running before GEM_CHECK_LIB 
(libquicktime).  libquicktime is needed for pdp and pidip on Mac OS  
X, though Tom mentioned the possibility of adding support for Apple  
Quicktime, which would be ideal.  Perhaps that's the best solution  
then: help Tom get PDP supporting Apple Quicktime.


> at least that is the way, how debian handles it (or handled it! i  
> haven't looked at the way how debian packages are built since they  
> started the great unified build-system a few years ago)


This is something to think about.  I'd love to see CPU-specific auto- 
builds of Pd-extended, and I don't think it would be too hard to do.

.hc


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

As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously.         - Benjamin Franklin