Simplify mythdirs.cpp and remove RUNPREFIX

[ulmus-scott]

@jhoyt4 I think this will break for the application bundle on macOS, so if there is some way to determine the program is in an application bundle, a suggested change would be welcome.

@rcrdnalor I don't think the python bindings will work fully if moved after install. Could the uses of INSTALL_PREFIX be replaced with some code using relative paths from the python file?

Checklist

• contribution does not duplicate one of our existing pull requests
• contribution is in a branch rebased against master
• code compiles successfully without errors
• code follows the MythTV Coding Standards
• documentation added/updated/removed where necessary
• commits are logically organised and have good commit messages

[rcrdnalor]

Debian has a non-standard installation scheme for Python packages(1):
Regardless what you define as PREFIX, a make or cmake installs
the MythTV package in usr/local/lib/python3.x/dist-packages/.
This is the default location if you use deb-light (2) as well
(see https://github.com/MythTV/packaging/tree/master/deb-light)
Only a special environmet variable causes Debian to install
Python packages in /usr/lib/python3/dist-packages:
See path in make for debian
This is used by Ubuntu/Debian package builds and conforms
to the Debian/Ubuntu standards.

MythTVs Python bindings need to know the location of the
metadata grabber scripts (usually at /usr[/local]/share/mythtv/metadata)

Thus, depending on the way how MythTV is compiled and installed,
it can happen that the metadata scripts a installed under /usr/share/mythtv
and the python bindings are under /usr/local/lib.
For the python bindings, there is no chance to figure
that out at runtime, it is defined at compile time via the
INSTALL_PREFIX. Guessing that path at runtime is not an option.

(1) On Debian/Ubuntu, one gets:
$ python3
Python 3.12.3 (main, Jan 8 2026, 11:30:50) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import sysconfig
sysconfig.get_paths()
{'stdlib': '/usr/lib/python3.12',
'platstdlib': '/usr/lib/python3.12',
'purelib': '/usr/local/lib/python3.12/dist-packages',
'platlib': '/usr/local/lib/python3.12/dist-packages',
'include': '/usr/include/python3.12',
'platinclude': '/usr/include/python3.12',
'scripts': '/usr/local/bin',
'data': '/usr/local'
}

import sys
sys.path
['',
'/usr/lib/python312.zip',
'/usr/lib/python3.12',
'/usr/lib/python3.12/lib-dynload',
'/usr/local/lib/python3.12/dist-packages',
'/usr/lib/python3/dist-packages']

and using that environment variable:

$ DEB_PYTHON_INSTALL_LAYOUT=deb_system python3
Python 3.12.3 (main, Jan 8 2026, 11:30:50) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

import sysconfig
sysconfig.get_paths()
{'stdlib': '/usr/lib/python3.12',
'platstdlib': '/usr/lib/python3.12',
'purelib': '/usr/lib/python3/dist-packages',
'platlib': '/usr/lib/python3/dist-packages',
'include': '/usr/include/python3.12',
'platinclude': '/usr/include/python3.12',
'scripts': '/usr/bin',
'data': '/usr'
}
import sys
sys.path
['',
'/usr/lib/python312.zip',
'/usr/lib/python3.12',
'/usr/lib/python3.12/lib-dynload',
'/usr/local/lib/python3.12/dist-packages',
'/usr/lib/python3/dist-packages']

Note the difference in 'purelib' path.

(2) ad @bennettpeter : Many thanks for the deb-light framework, it implements great testing features!

[ulmus-scott]

@rcrdnalor OK, thanks for the information.

The uses in the Python bindings want the .../share/mythtv directory.

The only other use wants the .../bin directory.

mythtv/mythtv/programs/scripts/hardwareprofile/distros/mythtv_data/data_mythtv.py

Lines 54 to 55 in 839503c

	execpath = os.path.join(MythTV.static.INSTALL_PREFIX,
	'bin', executable)

However, I think that use could use relative paths since it is installed under share/mythtv, unless you think it is a bad idea.

I think calling the remaining use PYTHON_SCRIPT_DIR_PREFIX where it includes share/mythtv is better

[linuxdude42]

I've asked amessina to chime in on this since he's done some work with packaging.

[amessina]

Thanks @linuxdude42. I'll take a look in the near future, especially if I can backport to fixes/35 as I don't run master.

When I was converting to CMAKE, mostly I was looking to get the Fedora Qt6 CMAKE build to use the standard routine where build and install occur in separate sections of the rpmbuild:

%build
%cmake
%cmake_build

%install
%cmake_install

That way I didn't need to do things like...

# Relocate build into the buildroot
mv %{_builddir}/install %{buildroot}%{_prefix}

# Relocate perl inside the buildroot
mv %{buildroot}%{_datadir}/perl5/%(perl -v | grep -Eo '5.[[:digit:]][[:digit:]]') %{buildroot}%{perl_vendorlib}

[jhoyt4]

My apologies for the delayed response, I've been away from a computer this past week.

You can detect a mac app bundle using some functions in <CoreFoundation/CoreFoundation.h>.

Attached is an example I stumbled on and verified to work.
detect_app_bundle.cpp

It will need the -framework CoreFoundation linker flag added to cmake.

I can confirm an app bundle runs ok even moved from the cmake output location, but the python based metadata grabbers no longer work.

[ulmus-scott]

I will need to add back RUNPREFIX for the Python bindings, since Roland says there is no other way for the Python bindings to find the MythTV scripts.

@jhoyt4 Thanks for the example. However, am I correct in understanding that no additional change is needed for macOS in mythdirs.cpp?

[ulmus-scott]

I restored the use of RUNPREFIX for the Python bindings.

However, I don't think configure/qmake used prefix and runprefix correctly based on their descriptions.

[jhoyt4]

@jhoyt4 Thanks for the example. However, am I correct in understanding that no additional change is needed for macOS in mythdirs.cpp?

I rebased and everything except the python grabbers appear to be working. I added some debug log messages locally and installprefix appears to get set correctly. Unfortunately, the metadata grabbers appear to now fail.

It appears the python issue is a macports problem. After re-building with homebrew everything looks good.

[ulmus-scott]

@jhoyt4 I think 0310398 was missing the initial path for site-packages and lib-dynload, see newest commit.

[jhoyt4]

@jhoyt4 I think 0310398 was missing the initial path for site-packages and lib-dynload, see newest commit.

Just tested on homebrew and macports. Homebrew still works without issue, macports is still failing, but that's due to lxml not being included in the app bundle for some reason. I still believe that issue to be an unrelated macports issue.

Since the mac frontend weekly builds use homebrew, I'd say this is safe to proceed while I look into the macports issue.

[rcrdnalor]

I use packaging/deb-light a lot for development and testing:
See test.sh
It uses DMYTH_RUN_PREFIX
Is there a new way to establish this setup?

[ulmus-scott]

The settings for CMake and configure are still the same. I did tweak their descriptions since CMake's MYTH_RUN_PREFIX and configure's runprefix are now only used by the Python bindings.

I had thought about changing the settings names, but I decided to leave them as is for now.

[amessina]

I've asked amessina to chime in on this since he's done some work with packaging.

Since it looks like the v36.0 release is imminent, I think I'd be able to user-test this out by patching it into the equivalent of a v36 tarball release. Is there any special handling used to create the release tarballs, or could I just base it on a git archive from the fixes/36 branch plugged into my RPM packaging pipeline?

[linuxdude42]

There's no special handling. It's essentially updating the SRC_VERSION file and setting a tag.

[amessina]

There's no special handling. It's essentially updating the SRC_VERSION file and setting a tag.

Ok, thanks. I'll get a start on testing this weekend.

[amessina]

I've asked amessina to chime in on this since he's done some work with packaging.

Since it looks like the v36.0 release is imminent, I think I'd be able to user-test this out by patching it into the equivalent of a v36 tarball release. Is there any special handling used to create the release tarballs, or could I just base it on a git archive from the fixes/36 branch plugged into my RPM packaging pipeline?

Builds ok for Fedora 43 with MYTH_RUN_PREFIX effectively unchanged supporting the Python bindings.