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

Quoting Hans-Christoph Steiner hans@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

On 9/29/06, Mathieu Bouchard matju@artengine.ca wrote:

Is there a way to enable static linking, at least for some libraries? It doesn't matter much that the gem .so becomes bigger, as long as it's not so much bigger, and that it's easier to carry around.

On the platform in question, OSX, freetype and FTGL are statically linked. Quicktime and OpenGL are defaults in every OSX install. We have incorporated code like GLEW and the model loader directly into the source tree.

There is nothing to install for GEM on OSX beyond having a working Pd and dropping the Gem.pd_darwin in the extra folder.

On 9/30/06, B. Bogart ben@ekran.org wrote:

or if there is a NURBS chapter in one of those openGL books that would be good too.

Chapter 12 of the Red Book.