Opened 15 years ago

Closed 15 years ago

#1152 closed patch (fixed)

Commflag, etc., for OSX bundled apps + cleanups

Reported by: dave@… Owned by: Nigel
Priority: minor Milestone: 0.20
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no


The enclosed patch allows auxilliary executables in OSX application bundles to work. It also cleans up and refactors some of the uses of mythcontext.

Attachments (1)

commflag.patch (22.9 KB) - added by dave@… 15 years ago.

Download all attachments as: .zip

Change History (10)

Changed 15 years ago by dave@…

Attachment: commflag.patch added

comment:1 Changed 15 years ago by danielk

Milestone: 0.20
Owner: changed from Isaac Richards to Nigel
Priority: majorminor

comment:2 Changed 15 years ago by Nigel

Status: newassigned

About half of the patches in osx-packager have been applied. I am not comfortable with the MythContext changes yet - a lot of testing will be required.

comment:3 Changed 15 years ago by Nigel

Resolution: fixed
Status: assignedclosed

(In [10957]) Add symlinks to allow helper apps like "bin/transcode" to be found in the pkg. Much easier than changing the source code. Closes #1152

comment:4 Changed 15 years ago by dave@…

Resolution: fixed
Status: closedreopened

I don't think you can solve the same problems by adding symlinks. Doesn't using an INSTALLPREFIX that's compiled into the program break down as soon as someone decides to drag their MythTV package into a different folder? Doesn't it interfere with testability?

I get the impression this patch was dismissed without giving it much consideration. A great deal of careful thinking went into it and it significantly improves the level of abstraction behind mythcontext; IMO it deserves a second look.

comment:5 Changed 15 years ago by Nigel

Hi Dave. I did spend a good while looking at your re-engineering of all the path stuff in MythContext. It works, and is very tidy, but ultimately I didn't see the need to apply it when there is a much easier way?
We currently find the location of the running binary, and if it has ".app/Contents/MacOS", uses that as the runtime prefix (around line 320 of mythcontext.cpp). Dragging the package to a different folder will be detected next time the app starts.
In my limited testing, the bin symlink seems to work, because it replicates the install tree that a "make install" would create.

comment:6 Changed 15 years ago by awk@…

Actually - I've been wondering about this recently.

Why are 'helper apps' like mythfilldatabase and mythcommflag even built as bundles ? They don't need to be, they have no associated resources. It seems like this is just a byproduct of the way qmake builds them. If the .pro files were updated so that on Mac OS X these items (and probably one or two others) were built as simple command line executables, just like they are on Linux this whole problem would go away. There would be no need for path mangling in the other apps and the default path settings would just work etc. etc.

There are some other aspects of the qmake/link/output style that I question too. Why - for example do I need to place the AVCServices.framework inside the bundle for mythfrontend ? It's not talking to my Settop - the only app that does that is the backend (in this case mythbackend does need to be a bundle for that framework inclusion).

comment:7 Changed 15 years ago by Nigel

(In [11258]) Packaged mtd binary had the wrong library paths - I had forgotten to run &PackagedExecutable?() on it. Fixed that, and added some more Verbose. See #1152

comment:8 Changed 15 years ago by anonymous

Should this ticket be closed, then?

comment:9 Changed 15 years ago by Nigel

Resolution: fixed
Status: reopenedclosed

I haven't heard anyone complain that the bundles don't work (i.e. the original problem has been fixed), so I will close it. Sorry Dave. It really was nice code

Note: See TracTickets for help on using tickets.