[mythtv] CMake

[David Hampton]

On Tue, 2024-07-16 at 19:11 -0400, Scott Theisen wrote: 
> On 7/15/24 18:01, David Hampton via mythtv-dev wrote: 
> > On Fri, 2024-07-12 at 17:51 -0400, Scott Theisen wrote: 
> > >  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:  
>   
> > > > > > 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. 
> > 
> > If you don't want to build the plugins, there's already an option
> > for
> > that.  You could perform most of your builds with out compiling the
> > plugins, and then perform a final build with plugins at the end to
> > see
> > if anything broke. 
> 
>  I do want to build the plugins, however, so that any change always
> compiles everything.  I want to know if any changes I make require
> changes to the plugins so those changes can be in the same commit,
> not a separate later commit.
> 
> something like this might work:
>  cmake --preset qt5 -DMYTH_BUILD_PLUGINS=OFF
>  cmake --preset qt5 -B build-no-install -
> DCMAKE_INSTALL_PREFIX=./build-no-install/install
> 
>  and usually run
>  cmake --build build-no-install
>  and run 
>  cmake --build build-qt5
>  when I want to run that version of MythTV.

If you run those commands, you're re-running the top level
orchestrator.  That only checks that the sub-project builds have been
performed.  It has no knowledge of what happens inside the sub-builds,
and can't peek into them to see if any of the files have changed.  Its
up to each the sub-projects to determine if its files have changed and
it needs to rebuild.  You'll need to run something like this to ask the
sub-projects to rebuild.

  cmake --build build-qt5/MythTV-prefix/src/MythTV-build
  cmake --build build-qt5/MythPlugins-prefix/src/MythPlugins-build

Or just delete the build tree and recreate it again.  (I do this all
the time.)

A third approach would be to delete the top-level orchestrator status
files that tell it the sub-projects have been built.  The next time you
run the orchestrator, it will ask each of the sub-projects to
build/install.

  rm build-android-v8-qt5-libs/*-prefix/src/*-stamp/*-build
  cmake --build build-qt5

It also appears that using the --clean-first argument will force a
rebuild, but it will rebuild all files and depends on ccache to produce
a shorter build time.

  cmake --build build-qt5 --clean-first

And....

While re-reading the cmake ExternalProject documentation last night, I
found there is a keyword to force the sub-project to always be built. 
(The equivalent of the third approach above.)  Adding this to the top-
level CMakeLists.txt should produce behavior similar to the traditional
build behavior.  Its not going to be exactly the same, because cmake
interleaves the build and install steps of each sub-project, whereas
make builds everything in one step and installs everything in a second
step.  You will see the intermediate libraries and executables get
relinked each time (because the installed libraries from the earlier
sub-projects just had their timestamps updated).

I've added two new values to the MythOptions.cmake file.

LIBS_USE_INSTALLED: This affects the cmake configuration phase.  When
set (default on) cmake will reuse the libraries from a previous build.
It will only create the framework to build a library if it can't find
an earlier version.  This will let you force a single rebuild of the
libraries even if they are already installed.

LIBS_ALWAYS_REBUILD: This affects the cmake build phase.  When set
(default off) cmake will rebuild the libraries each time you issue a
'cmake --build' command.  This will let you force rebuild of the
libraries every time you recompile.  (This option only make sense if
you set LIBS_USE_INSTALLED=OFF.)

The MythTV and MythPlugins directories will now always be rebuilt.

These two options can be overridden in either of the build overrides
files:

    ~/.config/MythTV/BuildOverridesPre.cmake
    ~/.config/MythTV/BuildOverridesPost.cmake

Add the following two lines:

    set(LIBS_USE_INSTALLED OFF)
    set(LIBS_ALWAYS_REBUILD ON)

You can make your overrides unconditional, or conditional based on the
build directory name (or whatever other condition you choose).  Cmake
is essentially a language that describes a build process, so it
supports variables and 'if' statements.

...

> > Everything under
> > mythtv/external should be ripped out and replaced by patches
> > against
> > original sources.  MythTV should no longer ship the source code for
> > any
> > library that it uses.  It should use system libraries if at all
> > possible, and if not, it should use package maintainer's source
> > code
> > with locally applied patches.  This is something that's trivial for
> > cmake to do, and hard for make to do.  I'm hoping that all your
> > FFmpeg
> > work will help us get to this point with FFmpeg where it can be
> > ripped
> > out of the MythTV sources. 
> 
>  Not all systems have the required libraries available as packages
> (libudfread is not widely available, EL 8 does not have official
> packages for libbluray) or the version is too old (libexiv2 0.28 is
> needed for C++17 support).

Agreed.  I've run into all those issues.  The cmake builds are set up
so exiv2 source is pulled and built for android, and that process was
tested for linux builds as well.  ISTR some issue with linux packagers
stating that downloading source while building a package would result
an immediate rejection.  I think that's why I didn't make the change to
download/build exiv2 for all builds.  I still think we should try to
get rid of the embedded libraries by pushing them into the
distributions, but I don't have the time (or will) to maintain them on
multiple distros.

> While applying patches sounds nice in theory, I'm not sure how well
> it would work since different versions could break the patches or
> require different or other patches.

Library versions don't change unless you update the cmake files.  When
you do that, also need to update the patch to apply to the new version
of the library source.  

David