[mythtv] CMake

[Scott Theisen]

On 7/12/24 14:37, David Hampton via mythtv-dev wrote:
> On Fri, 2024-07-12 at 04:02 +0000, Gary Buhrmaster wrote:
>> On Fri, Jul 12, 2024 at 2:14 AM Scott Theisen
>> <scott.the.elm at gmail.com>  wrote:
>>> How do you uninstall the installed programs?
> CMake builds don't create an uninstall target, but it would be possible
> for us to add one.
>
> https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake
>

I think that is an incredibly stupid design decision on CMake's part.  
We should definitely have a top level uninstall target that uninstalls 
everything.  I would also like a target to uninstall only the plugins 
(since they are optional).  Uninstalling just MythTV or any of the 
included libraries doesn't make sense to me since then you would have to 
account for the dependencies.

>>> Is there a way to only build, but not install, the plugins?
> I tried a couple of experiments this morning.  It could be done with an
> option at the top level, but it wouldn't be the prettiest given
> where/how the cmake ExternalProject allows substitution.  It seems like
> the CMakefile would need to provide an alternative ExternalProject that
> doesn't perform an install, and then build one or the other of those
> projects based on an option.  To switch from installing to not
> installing the plugins you would also have to do a complete rebuild
> from the top level.

I have never used any of the plugins and I don't really care if they are 
installed as long as they don't do anything or can be easily uninstalled 
right after installing.

I assume that the programs (only mythfrontend?) automatically look for 
installed plugins.  If that could be disabled or if each plugin must be 
explicitly enabled, I don't think it would matter if they are installed.

>>> Can you build but not install the project?  (e.g. when making
>>> further changes to the code while running a test with different
>>> changes.)
> Once you've built/installed the super-project the first time, you can
> easily compile just the MythTV sub-project.  This is described in the
> README.CMake.md file.  You can compile just the mythtv directory from
> the top level:
>
>    $ cmake --build <build-dir>/MythTV-prefix/src/MythTV-build
>    $ cmake --install <build-dir>/MythTV-prefix/src/MythTV-build
>
> Or you can change into the MythTV build directory and compile from
> there.
>
>    $ cd <build-dir>/MythTV-prefix/src/MythTV-build
>    $ cmake --build .
>    $ cmake --install .
>
> Or if you're working on FFmpeg:
>
>    $ cd <build-dir>/FFmpeg-prefix/src/FFmpeg-build
>    $ cmake --build .
>    $ cmake --install .

Yes, but changes in FFmpeg (or any other included library) would require 
a rebuild of and possible changes to MythTV and changes in MythTV would 
require a rebuild of and possible changes to the plugins.

So I'm not sure building only one part really makes sense.

>> These (to me) are all related, as the current
>> CMake recipes do not support what are
>> considered by some to support the normal
>> build/install/uninstall workflow.  The
>> recipes can work for building packages,
>> but more work seems to be needed to
>> make this work as developers (and some
>> users who build from source) would
>> want/expect.
> The normal 'make' build/install/uninstall workflow.  I think this is a
> pretty standard 'cmake' workflow.
>
> The current design is that the top level super-project is only an
> orchestrator, building anywhere from 6 to 32 sub-projects.  Each sub-
> project is built and installed before the next is started.  I don't
> know of any way to build the sub-projects without installing them.  (I
> suppose that you could omit the install stage for each sub-project, but
> then the library/include search paths for every subsequent sub-project
> would get longer and longer.)  Perhaps there is another way, but I
> don't think so.  I will readily admit that I am not a cmake expert.
>
> Sub-project designs seem pretty common with cmake builds.  Sub-projects
> completely isolate the imported libraries from the main projects,
> guaranteeing API boundaries.  That actually creates an issue because
> MythTV doesn't respect the FFmpeg API and directly calls several
> internal functions.  I overcame that API violation by adding an extra
> step to the FFmpeg sub-project to install several internal header
> files.

I had previously reduced the use of internal FFmpeg functions and I am 
working on removing the last few uses now.  However, there are still 
functions added by MythTV in public headers among other changes.

> A big part of the reason for my choosing the sub-project design for
> MythTV is that linux/android/win builds are all done exactly the same
> way.  The difference between these builds comes down to the number of
> sub-projects and the arguments to the sub-projects.  It also becomes
> almost trivial to replace an embedded library with a system library.
> And yes, I was thinking of FFmpeg and exiv2 when I chose this design
> and chose to build those libraries as separate sub-projects instead of
> as part of the mythtv sub-project.
>
> I do understand that this is different from the current make
> implementation that builds all of the libraries and MythTV together in
> one fell swoop, and then installs them.  I think its better in some
> ways.  For example, with this design you only have to compile and
> install the mythtv version of FFmpeg once, and all subsequent builds
> (even complete rebuilds) will treat that installed version of mythtv
> FFmpeg as a system library.  For everyone other than you and Peter who
> are actually modifying FFmpeg, I consider that a win.  Its easy enough
> to force a rebuild of mythtv FFmpeg any time you want.  Just delete the
> installed mythtv FFmpeg and rebuild the super-project.

A top level build would also build and install a modified FFmpeg, 
replacing the previously installed version, right?

>
> The most similar thing to the current 'make' workflow would be to
> compile the entire super-project once, and then compile/install from
> the MythTV-build directory as often as you want.
>

I think the most similar would be to have two build targets: one that 
installs to wherever it did before and the other with

-DCMAKE_INSTALL_PREFIX=<install_location>

set somewhere else (e.g. /tmp or an install folder inside the build 
folder that CMake creates) so that it preserves the API boundaries and 
behaves the same, but won't effect running programs or

Since we use ccache and all of the build artifacts are in CMake's build 
folders, I think this would work and not cause a significant delay when 
switching between the two build targets.

How does CMake behave when you call

$ cmake --preset qt5 -DCMAKE_INSTALL_PREFIX=<install_location>

more than once?  Create a new differently named folder or override the 
current one?

Also, you should probably mention the qt6 preset in README.CMake.md, David.

Regards,
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20240712/cbb54f0f/attachment.htm>