Michael T. Dean wrote:
Robert Johnston wrote:
On 30/10/05, Michael T. Dean <[EMAIL PROTECTED]> wrote:
Robert Johnston wrote:
Incorrect. You can pass --disable-frontend and/or --disable-backend if
you want to make a FE-Only or BE-Only machine.
Yeah, if you don't want it to build. Those are porting only
options--they are /not/ valid options on Linux. See
http://svn.mythtv.org/trac/browser/trunk/mythtv/configure?rev=7650
lines
2740 and 2747--and especially lines 2741 and 2748.
These USED to be valid options to build a front-end only system (As it
seems very wasteful to have to build the whole of the backend, just to
never use it, especially on something like an XBOX-frontend, which
will NEVER be able to offer backend functionality, and building the
binaries (As well as keeping them) will only waste CPU time and HDD
space).
These were changed in Rev. 7577 to add the warnings mentioned above,
Right, but the warnings were added because of the sheer number of
posts/tickets where people reported that they couldn't build their
"lightweight" MythTV system using "--disable-backend" or
"--disable-frontend".
Here's the commit message where the options were first added. Note
the "so it should be considered as something useful only for porting
the backend," and "The basic aim here" parts.
http://www.gossamer-threads.com/lists/mythtv/commits/136628#136628
and TBH I think changing this breaks the whole "Client-Server"
functionality that Myth is supposed to be promoting, with independant
multiple frontends and multiple backends. It used to be that a backend
machine didn't require the behemoth that is X to compile, or run, but
with these dependancies, it makes what should be a small(er) program
with only the dependancies on what it needs become a huge thing that's
not efficient at all.
AIUI, Isaac has (rightly, IMHO) taken the stance that a "few" extra
megabytes of installed applications on a system that processes
multi-gigabyte files does not provide sufficient cause to justify the
work entailed in separating the two such that each is completely
independent of the other. If you really want that lightweight
frontend or backend, though, feel free to submit patches. ;)
As a matter of fact, the same applies to
mythplugins--you need the same version of mythplugins as the
version of
mythtv.
That's also incorrect. MythPlugins have to be built against the same
version of libMyth, but you can take an old version of the plugins
source, as long as it's built against the same version of libMyth as
the MythFrontend you are wanting to load them from.
Unless there are changes that break compatibility. This includes
incompatible changes to the myth protocol version, the DB schema
version, the libraries used by the plugins (i.e.
http://svn.mythtv.org/trac/ticket/531 ), and ...
In thoery, each "Plugin" should handle it's own "DB Schema", as they
should be interchangeable. IOW, MythWeather should not be touching
MythVideo's DB entries, and MythTV should not be changing MythNews'
schema.
This would mean that you could mix-and-match between Plugins/MythTV
versions, with no compatibility issues.
Yes, but MythWeb is actually more of a completely independent frontend
than a "plugin," so it /requires/ knowlege of the DB schema. This is
actually why the current MythWeb can corrupt custom recording rules
and other features new to the DB schema--it hasn't yet been completely
updated for some of the changes.
And, in /all/ cases, doing so is *not* a "supported"
configuration--which was the point I was trying to make. Unless, of
course, you're volunteering to provide support for all possible version
combinations users may wish to try.
Now, I'm not going that far. But you *should* be able to compile a
backend-only system without anything breaking, as it's meant to work
independantly of any frontends that may be attached to it. Likewise
with the Frontend-Only compilation. If there is functionality that is
used in both the frontend and backend, it should be modularised so it
can be used in both independantly (Moved into libmyth, perhaps?).
Otherwise, there's not much point in having seperate front-end and
back-end programs, and the whole thing might just as well be one
massively-threaded monolithic program.
My £0.02 ($0.0355157USD)
IMHO, having the mythbackend on disk on my frontend or the
mythfrontend on disk on my backend is not a big deal, but being able
to run mythbackend without starting mythfrontend or vice-versa is
critical.
As for breaking the client/server functionality, it's hard enough
getting people to understand what they do and don't need with just a
"mythtv" program that gets installed on all their Myth
boxes--regardless of whether they're dedicated backends or dedicated
frontends or combined frontend/backend boxes. I can only imagine how
complex this would get with mythfrontend, mythbackend, and
libmyth--and people trying to use varying versions of mythlib with
mythfrontend/mythbackend/mythplugins/whatever.
I'll admit it could be made a more elegant solution, but I'd rather
have new features like mythui or mfd than an opportunity to save 100MB
storage space (which is enough space for about 6 minutes of relatively
low-quality video ;). Even if it turned out to save 500MB, I don't
see the value in the savings.
Mike
_______________________________________________
mythtv-users mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Hi I'm Bryan and I'm a Gentoo freak
<dawns flame proof suit>
I like being able to have a BE only system without X and the like
because its less maintenance especially since to build the FE I not only
need X, but Qt, some dm, and other assorted libraries. For a system
that runs a process in the background that's a lot of cruft to have
floating around. It is true that I have gobs of disk space available
and adding those extra libraries isn't a big deal but it has the ability
to create dependancy hell, an example being last spring's DST bug in
Qt. If I had other software that used Qt and needed the newer version I
would have been in trouble since for a few days the only available work
around was 1) a hack or 2) downgrade Qt. Fortunately I was able to
downgrade Qt. Now if for some reason Myth has a dependancy on some new
verison of Qt and I have other GUI apps running on that system that rely
on deprecated functionality/bugs it would be nice to be able to build BE
only and not have to upgrade Qt because the FE which will never be used
depends on it.
</flame proof suit>
I do realize if I want it I am free (as in speech) to submit a patch.
Just my $.02
--Bryan
_______________________________________________
mythtv-users mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
