getting rid of lone SDK symlink

[Myk Melez]

Rocketeers!

Git on Windows doesn't support symlinks (issue 224), and the Add-on SDK code has one symlink, python-lib/cuddlefish/Test\ App.app/Contents/Resources, which complicates work on Windows.

For example, one can't share a local clone between Mac and Windows machines using a shared disk, and one can't spin builds on Windows.

In the long run, Git should add support for symlinks on Windows. In the short run, how can we get rid of this symlink?

-myk

[Mark Hammond]

On 14/09/2011 10:16 AM, Myk Melez wrote:
> Rocketeers!
>
> Git on Windows doesn't support symlinks (issue 224

> <http://code.google.com/p/msysgit/issues/detail?id=224>), and the Add-on
> SDK code has one symlink, /python-lib/cuddlefish/Test\
> App.app/Contents/Resources/, which complicates work on Windows.

>
> For example, one can't share a local clone between Mac and Windows
> machines using a shared disk, and one can't spin builds on Windows.
>
> In the long run, Git should add support for symlinks on Windows. In the
> short run, how can we get rid of this symlink?

Excuse my ignorance and my laziness in not figuring this out for myself,
but what is the target of the link and what is the file/directory used for?

Mark

[Myk Melez]

On 2011-09-16 15:24, Mark Hammond wrote:
> Excuse my ignorance and my laziness in not figuring this out for
> myself, but what is the target of the link and what is the
> file/directory used for?

python-lib/cuddlefish/Test\
App.app/Contents/Resources points to ../../app-extension, i.e.
python-lib/cuddlefish/app-extension, and it's only used on Mac in `cfx
run`, and perhaps only for XULRunner.

There's a comment in __init__.py that seems like an explanation of it,
although I don't quite understand what it is trying to say:

https://github.com/mozilla/addon-sdk/blob/master/python-lib/cuddlefish/__init__.py#L680

-myk

[Brian Warner]

I suspect the utility of this has been lost or made redundant at some
point. The way I follow the code, app_extension_dir (around line 680) is
either pointed at python-lib/cuddlefish/app-extension, or at a symlink
that points to the same thing. So the only way to distinguish which one
you get is to use some sort of pathname-manipulation function on that
string (like os.path.dirname). It gets passed to three different places:

cuddlefish.rdf.gen_manifest (as template_root_dir=)
cuddlefish.xpi.build_xpi (as template_root_dir=)
cuddlefish.runner.run_app (as harness_root_dir=)

gen_manifest() only uses it to create a filename for the install.rdf it
creates. build_xpi() only uses it to find files that should be copied
into the XPI. So those two don't matter.

run_app() has three uses. The first is to add the pathname to the
addons= list, which gets used by xulrunner.Profile.install_addon() but
doesn't appear to look too closely at the parent directory part of the
name. The second is to locate and populate the harness-options.json
file. The third is to calculate the pathname of the application.ini file
and passes it into xulrunner's "cmdargs", where it is passed into the
sys.argv[] of a child process (probably /usr/bin/firefox or xulrunner).

So, unless xulrunner behaves differently if you point it at a path with
"Test.app" in the middle, I don't see how this code could affect
anything. I suggest we remove it (and the whole "Test App.app"
directory) and see what happens.

cheers,
-Brian

[Brian Warner]

On 9/19/11 3:49 PM, Brian Warner wrote:

> So, unless xulrunner behaves differently if you point it at a path with
> "Test.app" in the middle, I don't see how this code could affect
> anything. I suggest we remove it (and the whole "Test App.app"
> directory) and see what happens.

Incidentally, I just opened
https://bugzilla.mozilla.org/show_bug.cgi?id=687706 with a patch.

cheers,
-Brian