Ticket #240 (closed defect: invalid)

Opened 5 years ago

Last modified 4 years ago

setup install does not preserve MacOS X resource forks

Reported by: guest Owned by:
Priority: normal Milestone: _|_
Component: Cabal library Version: 1.2.3.0
Severity: normal Keywords:
Cc: Difficulty: normal
GHC Version: 6.8.2 Platform: Mac OS

Description

I use the attached Setup.lhs file to do some Mac-related magic (which I unfortunately do not understand) on files built with wxhaskell on MacOS X. The key point about this magic is that it allows me to run a GUI from the command line. Without doing the magic, the GUI will open, but it will not react to any user interaction.

I think the problem is that whatever mechanism we use to copy the binary over (say to /usr/local/bin) does not preserve the magic. That is, if I run it directly after a runhaskell Setup install, I get the non-reactive GUI. If I do a cp geni /usr/local/bin by hand, then the GUI reacts, presumably because on MacOS X cp also copies the magic over.

Sorry for being so vague. Let me know if I can help in any way. -- Eric Kow

Attachments

Setup.lhs Download (2.1 KB) - added by guest 5 years ago.

Change History

Changed 5 years ago by guest

Changed 5 years ago by guest

Probably the simplest fix for your problem is to run macosx-app after the binary is installed, using the postInst hook. See

 http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg00129.html

-Judah

Changed 5 years ago by duncan

  • platform set to Mac OS

If you can figure out what Haskell code we can use to copy and preserve this stuff that'd be great. I don't think it's ok to call out to an external cp program.

Changed 4 years ago by duncan

  • milestone set to _|_

Note it will also not work in general to run something after installation. Packages have to be able to be installed into a temp dir to make binary packages.

So, what do we need... We need to know what is actually going on. We need to know the proper documented way to copy darwin executable files preserving resource forks. We need someone who can test any solution.

Assigning to milestone _|_ because we need more info before we can proceed.

Changed 4 years ago by kowey

  • status changed from new to closed
  • resolution set to invalid

I claim that my diagnosis of this problem as being related to resource forks was completely bogus.

The real problem is that in MacOS X, my graphical application needs to be stored in an application bundle, so instead of calling foo I need to call foo.app/Contents/MacOS/foo

This leads to some hoops which makes it impossible to just cabal install foo, but at least they are simpler hoops

Note: See TracTickets for help on using tickets.