Debugger, Nested Bundles & @executable_path

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Debugger, Nested Bundles & @executable_path
Date: 2007-04-14 14:56:23
Message-ID: 4620EB97.9010704@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi

I've done a bit of research on the Debugger integration issue on OSX.
As it turns out, there is a nearly perfect solution for our problem -
with one little downside.
There is a macro @loader_path similar to @executeable_path - only that
it refers not to path of the top executable that was originally executed,
but rather to the path of the image (executable or shared lib) that
*actually* needs the library. So simply using @loader_path instead of
@executeable_path should make things "Just Work".

Sounds too good to be true, doesn't it - well - now that little downside.
@loader_path is only supported on OSX 10.4+ :-( grrr...

The only alternative I see is to symlink
Contents/Resources/Debugger.app/Contents/Frameworks to Contents/Frameworks,
and to run complete-bundle.sh twice - once for the main app, and once
for the Debugger (Running it twice isn't stricly needed, but it seems to
be cleaner). The major downside of this is that we we currently do isn't
only broken (in pratice) for the Debugger, but also (in theory) for
pg_dump and friends. It only works because libpq doesn't have any dependencies
that live inside the pgadmin bundle. :-(

So - Shall I go the symlink route, or do we want to consider dropping 10.3
support? It might be acceptable if 10.5 is going to be out by the time
1.8 is released...

Any opinions?

greetings, Florian Pflug

Browse pgadmin-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2007-04-14 15:53:09 [PATCH] Nested app support for complete-bundle.sh
Previous Message svn 2007-04-12 15:28:06 SVN Commit by hiroshi: r6194 - trunk/pgadmin3/debugger