[mythtv] [mythtv-commits] Ticket #4397: win32 dependancy resolver and build script

[buzz]

>
> I really don't care if people disagree with me. =)  The only thing I care
> about is code quality.  This script has a ways to go..
>

I'm glad, and I agree with your statement, when measured against
perfection.  it is getting better though, isn't it.

>
>
> The script appears to be seriously broken, in my opinion.

Really?    have you used it?   We welcome all positive feedback, but I'm
struggling to find the positive in that.


> Why is it
> installing tools that the developer should (IMO, at least)?


It's doing this because it's difficult, complex, easy to screw up, and not a
valuable use of a dveloper's time to spend days/weeks struggling to come to
terms with getting all the required stuff installed that Linux typically
comes with out-of-the-box.  I'd rather they fix mythtv bugs.


Why is it
> compiling qt4 from scratch?


for the same reason/s it's compiling QT3 from scratch:
1) only available as source-code, not binaries.
2) will probably require patches, QT3 did, so QT4 probably will to.


> Why is it grabbing patches from *trac*?
>

Where else would you have patches grabbed from?  These are patches that have
been found to have value by one of the Win32 coders/devs, and have not been
put into SVN yet, so the short-term solution is to put them here.    it's
not perfect, but it's the best we have at present.   ideas welcome.

>
> I think it would be quite productive to make some pre-compiled packages for
> the various dependencies, if none exist, rather than trying to compile them
> all..


I agree.     As it turns out, I have even written a tool to  do this, it's
called win32-packager.pl  All we need now is some place to store the
binaries for others to access.   ideas welcome.  :-)


> At the _very_ least, I'd think this should be split into a 'install
> dependencies', and 'build myth' scripts.  And, if the 'build myth' part is
> anything but 'configure, make, make install', then things need fixing in
> myth, not in a script.


I agree, splitting them out is probably clearer.....    But on the reverse
of the coin, why would anyone ever want to 'build myth' without first
installing the dependencies?     it's not like they get blindly re-installed
every time.   the script is very smart, and only does that once.

AGREED!... If anything is more complicated that 'configure; make ; make
install' then things need fixing in myth.  What that means is that things DO
need to be fixed in mythv.    What we need now is for all those things we've
identified (and many we haven't) to be fixed in myth so that we can remove
them from the script.    Are you offering your assistance?  It would
honestly be appreciated.


>
> > What we have now is a "tried and tested" methodology for getting each new
> > developer(or installation anyway) somewhere between 99-100% of the way
> > through these steps, without the otherwise guaranteed hair-pulling and
> > failures that would otherwise result.    We also have a consistent
> > approach, a documented method, and a shared knowledge that we would not
> > otherwise have.      Ok, so we have failures. Who cares, if we have more
> > successes that failures then it was valuable to those involved.
> >
> > How can you call that "never useful"?
>
> If any given checkout of svn revision X requires a script that's in version
> X+Y to work, then how can it be useable?


Actually, it's kinda the reverse at the moment:  Any given svn checkout of
revision X of the script actually attempts (by default) to compile a SVN
revision of Y where Y<X.    The SVN revision that will be attempted is
identified at line 50 in the script (about the 8th non-comment line ).

One current challenge is to keep the difference between X&Y as small as
possible, getting it to zero means we have achieved the goal of ful
integration of Win32 as a standard/functional build target, just like you
everyone wants (yourself included).

Buzz.


>
>
> Isaac
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20080425/0b9e7024/attachment.htm