<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 7/12/24 14:37, David Hampton via mythtv-dev wrote:<br>
<blockquote type="cite"
cite="mid:b45a5aca3147792c92c286fe75ff841c8e414d4e.camel@love2code.net">
<pre class="moz-quote-pre" wrap="">On Fri, 2024-07-12 at 04:02 +0000, Gary Buhrmaster wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On Fri, Jul 12, 2024 at 2:14 AM Scott Theisen
<a class="moz-txt-link-rfc2396E" href="mailto:scott.the.elm@gmail.com"><scott.the.elm@gmail.com></a> wrote:
</pre>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">How do you uninstall the installed programs?
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
CMake builds don't create an uninstall target, but it would be possible
for us to add one.
<a class="moz-txt-link-freetext" href="https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake">https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake</a>
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:b45a5aca3147792c92c286fe75ff841c8e414d4e.camel@love2code.net">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Is there a way to only build, but not install, the plugins?
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:b45a5aca3147792c92c286fe75ff841c8e414d4e.camel@love2code.net">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Can you build but not install the project? (e.g. when making
further changes to the code while running a test with different
changes.)
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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 .
</pre>
</blockquote>
<br>
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.<br>
<br>
So I'm not sure building only one part really makes sense.<br>
<br>
<blockquote type="cite"
cite="mid:b45a5aca3147792c92c286fe75ff841c8e414d4e.camel@love2code.net">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:b45a5aca3147792c92c286fe75ff841c8e414d4e.camel@love2code.net">
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<br>
A top level build would also build and install a modified FFmpeg,
replacing the previously installed version, right?<br>
<br>
<blockquote type="cite"
cite="mid:b45a5aca3147792c92c286fe75ff841c8e414d4e.camel@love2code.net">
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
<br>
I think the most similar would be to have two build targets: one
that installs to wherever it did before and the other with
<pre>-DCMAKE_INSTALL_PREFIX=<install_location></pre>
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 <br>
<br>
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.<br>
<br>
How does CMake behave when you call<br>
<pre>$ cmake --preset qt5 -DCMAKE_INSTALL_PREFIX=<install_location></pre>
more than once? Create a new differently named folder or override
the current one?<br>
<br>
Also, you should probably mention the qt6 preset in README.CMake.md,
David.<br>
<br>
Regards,<br>
Scott<br>
</body>
</html>