[mythtv] [mythtv-commits] mythtv commit: r25892 by robertm

buzz davidbuzz at gmail.com
Thu Sep 2 09:27:56 UTC 2010


> Putting them in a comment would be acceptable to me,


ok, let's start with this easy option, and make improvements to it as
motivated. :-)


> having to rush to
> fix the busted build script a dozen-odd times per year is not.  We
> just have way, way too little manpower looking at Windows to be able
> to spend 90% of that weffort trying to make the build script work.
> It's hard enough trying to keep Myth working on Windows.
>

Trust me, I know. ...   I'm the original author of win32-packager.pl   I
baby-sat tweaks/changes/etc to it for about two years.   Trust me, it's
better than what went before it ( nothing, not even a wiki page existed
then).

Sure it's complicated, but if linux didn't come with a compiler or with all
these dependancies build as pre-canned binaries, then MythTV on linux would
be complicated too!.  :-)


>
>
> That may be absolutely true, but on the other hand, switching versions
> from a known good to an unknown means a whole new round of
> troubleshooting as issues arise.
>

Generally it's been pretty few and far between though for anything outside
Mythtv/Qt themselves.


>
> > * It is harder ( impossible) to push any faults found with the
> dependancies
> > back upstream to the author/s if we are using an old version.
>
> We have never had the manpower to do this, either.  If we had a
> thriving Myth Windows community then this might be feasible, but as it
> stands maybe two of us devs and a half dozen users are doing anything
> worthwhile in this space, and I just don't have time for it.  As I try
> to do real, useful work in Windows, I'm already chasing build failures
> every single time I run the script.  It takes what would be an
> already-scant few hours of work I can put towards the Windows build
> per week and turns them into minutes.  I just can't keep up this way.
>

That's why I suggested a solution that gives you both the cache, and the
"master" URL/s.


>
> > My suggested solution is this:
> >
> > * always check the original URL, using a http HEAD request, and if it's
> not
> > available any more at that URL, throw a meaningful message describing the
> > fact that you should see if a newer version is available.  ( see
> > http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html section 9.4 )
> >
> > * after doing the above, if the file is still available AND it's at the
> > google code repository, download it from the google repo ( since it's
> > aparently faster).
> > * if the file is NOT in the google repo, but still at the primary URL,
> > download from the primary URL.  Optionally, if we wanted to be tricky, we
> > could auto-upload it direct to the google repo at this time, if we wanted
> > to.
>
> The Windows build script is already insanely overcomplicated as it is,
>

Yes, it is, isn't it..... so adding half a dozen lines isn't going to make
it any worse.


> and I just can't see myself doing this for all the reasons listed
> above-- if we had a full time Windows Build script maintainer, sure,
> but when two of us have to split time between trying to keep it
> building, trying to keep the script in line, and in the last few
> seconds left after that trying to improve windows features... well, if
> we go back to the old way, that will be the end of my involvement with
> the Windows port.  I don't have the time or the patience to spend 90%+
> of my time poking at a bash script.
>

[opinion]
I gave up baby-sitting the script and changes to it after it was obvious
that I was never going to be given commit access.

Apparently 26 major releases ( and dozens of other patches) of the script
wasnt good enough to give me SVN access. ( see
http://svn.mythtv.org/trac/ticket/4397 )

No wonder there's not a "big community" around Win32.   none of the "core
devs" gives a shit about it.   (  ok jonathan and nigel, who tried their
best, but never "owned"  the win32 platform to a point of loving it. )

[/opinion]

Buzz.


> Robert
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-dev/attachments/20100902/35571c6e/attachment.htm>


More information about the mythtv-dev mailing list