[mythtv] CMake

[David Hampton]

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:
> 
> I will chime in with my opinions (which are
> not to be considered facts, just opinions).
> 
> > 
> > I have not yet tried the new CMake based build system and I have a
> > few questions (mostly for David Hampton, but anyone can chime in):
> > 
> > When is it intended to replace configure?
> 
> I would like it to see it happen quickly, as
> configure is a maze of twisty passages
> with deadends and potential collapses.
> That said, see below...

I have no schedule.

> > 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

> > 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.

> > 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 .

> 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.

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.

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.

> On my infinite todo list is to take a look at
> the recipes to see if I can contribute, but
> I have no schedule for that effort.  Someone
> fluent in CMake (I am not, although I can,
> sometimes, muddle through), could probably
> submit some useful PRs quickly.

As I said, I'm not a cmake expert.  I would love for someone fluent in
cmake to look though our CMakefiles and offer suggestions.

> > Is there an easy way to specify additional compiler flags?
> 
> I have not checked the recipes to see if
> it works, but adding -DCMAKE_CXX_FLAGS
> (and -DCMAKE_C_FLAGS) to the build is
> the typical way to accomplish that.

That should work.

David