Opened 18 years ago
Closed 18 years ago
#1152 closed patch (fixed)
Commflag, etc., for OSX bundled apps + cleanups
| Reported by: | Owned by: | Nigel | |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.20 |
| Component: | mythtv | Version: | head |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
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)
Change History (10)
Changed 18 years ago by
| Attachment: | commflag.patch added |
|---|
comment:1 Changed 18 years ago by
| Milestone: | → 0.20 |
|---|---|
| Owner: | changed from Isaac Richards to Nigel |
| Priority: | major → minor |
comment:2 Changed 18 years ago by
| Status: | new → assigned |
|---|
comment:3 Changed 18 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:4 Changed 18 years ago by
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
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 18 years ago by
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 18 years ago by
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 18 years ago by
(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:9 Changed 18 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
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
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.