[vlc-devel] Re: Can't Build from Source, want to help with image filters/scaling and quality control

[Derk-Jan Hartman]

Sorry, you blame us for the fact that there is no standardization  
among the various linux distributions ?
VLC is very complicated and relies on a ton of libraries to be  
present. We cannot do QC on all of them, we cannot manage all of  
them, and we definitely cannot manage them on ALL linux distributions.

VLC is not a selfcontained application and nor do we want it to be  
because we would install everything double. The fact that linux has  
totally spun out of control where it concerns installation procedures  
and binary installation is not something we can solve, we need to  
live with it and unfortunately so will you.

Having "release" binaries for every distro is already a gigantic  
task. The make src system in contrib is a workaround sometimes at  
best, but should not be an advised path of action. The easiest in my  
eyes is using debian, installing binary vlc, then doing src-dep to  
get most the stuff the source depends on, and then work from there.

We don't live in a perfect world, we live in a world where we have  
too few developers working on this project.

DJ


On 27-feb-2007, at 19:10, Neil Woodall wrote:

> I have no need for 1394 support at this time (although if it  
> supports the old DVHS decks, I can think of a use), but that wasn't  
> really the point of the example. The point of the example was that  
> you do not have a published method for building the source and you  
> can't do quality control without a set of procedures for making the  
> product. The method you recommend on the Wiki, i.e. running "make  
> src" in the extra/contrib directory does not work and it's also  
> obvious from the "make src" method that you build specific  
> configurations for the various contrib sources and there is no  
> clear documentation on what configurations to build. In fact there  
> seems to be a lot of opinions on the forums about what to build for  
> ffMPEG. However, that impression could be the result of not fully  
> understanding all the options of the program.
>
> If you want to implement quality control to improve the product,  
> then every developer should be installing the libraries and  
> supporting source exactly the same way and should be able to  
> exactly duplicate the buildbot results for their configuration. If  
> some of the more obscure features are causing stability problems,  
> then you may want to have two procedures: one for main stream build  
> and one for the kitchen sink build. I'm also kind-of curious what  
> happens if your build machine crashes. How do you know that the new  
> system is installed the same way as before?
>
> Don't get me wrong, I like the structure of the program. But I need  
> a procedure for installing and building from the sources so that I  
> can recommend the use of the program without causing a support  
> nightmare for our Methodology group (they maintain source databases  
> and tools).
>
> In the distro.mak file in extra/contrib there is a list of programs  
> and the order they are compiled in the extra/contrib/src directory  
> and in that directory packages.mak list the download sites and  
> versions. I know that there is a Wiki page with the extra/contrib  
> source code sites and versions, but given my experience with the  
> Wiki, I don't trust that the information reflects what developers  
> are actually doing.
>
>
> On Feb 27, 2007, at 12:27 AM, Jean-Paul Saman wrote:
>
>> Neil Woodall wrote:
>>> Let me introduce myself. I'm a Fellow of DSP engineering at  
>>> Pixelworks, Inc (www.pixelworks.com). We build image processing  
>>> SOC's for TV's and projectors. We have started moving our  
>>> development environment from Windows to Linux, so we are looking  
>>> to replace some of our Image processing DSP tools.
>>> I've been trying to evaluate the viability of using VLC as a  
>>> shell for our company's image processing development (which would  
>>> add ~30 software/dsp engineers to the list of people working to  
>>> find and solve bugs for VLC along with some methodology engineers  
>>> for quality control), but I've been unable to build the package  
>>> from source using Fedora Core 5. I've tried using the forums for  
>>> help and emailing this list, but without any luck. I've also  
>>> looked at the commands given to the buildbot, searched the web,  
>>> etc...and can not find a solution.
>>> I finally gave up when trying to duplicate the buildbot set of  
>>> commands I got an error that byte_t was defined twice. Once in / 
>>> extras/contrib/include/libraw1394/raw1394.h and once in  include/ 
>>> vlc_common.h. Since libraw1394 is part of the make src  
>>> instructions (and I could find no other instructions on what to  
>>> include in extra/contrib... vs. /usr/lib location) this  
>>> definitely points to a bug in the make instructions.
>>
>> This is a known problem. It is a clash between 2 libraries  
>> defining byte_t in public headers. The former libraw1394 didn't  
>> define it. So in your case the solution should be to undef it in  
>> libraw/raw1394. Or not buildt in 1394 support at all.
>>
>>> I even downloaded the rpm for 0.8.5 so that I could verify that I  
>>> had all the required shared libraries and still could not build  
>>> 0.8.5 (or 0.8.6 or 0.8.6-bugfix or the trunk) from the sources.
>>
>> I don't have those problems with the RPM's. I use them myself for  
>> rebuilding om RH/FC/CentOS without problems. Could you share with  
>> us the error messages? That way we can help you.
>>
>>> I would still like to use VLC as a platform, but unless I can get  
>>> a reproducible process for building the application from the  
>>> sources, which at minimum means producing a step by step set of  
>>> instructions that goes from a clean install of Fedora Core 5 to  
>>> working application, we can not use VLC as a starting point.
>>> If we do use VLC, our contribution to the effort would be to  
>>> extend the image filters and scaling routines to use the Cell  
>>> SPE's, which would give the PS3 users something pretty special,  
>>> and I would probably insist (especially after my experience) that  
>>> our methodology department setup a nightly build(s) to be run on  
>>> our server farm. We would probably also look into actually trying  
>>> to verify that the build works, not just that it makes without  
>>> errors.
>>> BTW, one thing I would recommend for quality control purposes is  
>>> to change your nightly build process to start with a checkout of  
>>> the svn database to an empty directory for vlc and any source  
>>> code that would be built in the extra/contrib directory. I would  
>>> also recommend that you don't use external servers for getting  
>>> the source code that is in the extra/contrib directory or that  
>>> you statically link to, but instead store a copy on your svn  
>>> server and get it from there. That way when you tag a release,  
>>> you also tag ALL the make dependencies.
>>
>> That is what buidbot does.
>>
>> Gtz,
>> Jean-Paul Saman.
>>
>> -- 
>> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
>> To unsubscribe, please read http://developers.videolan.org/lists.html
>>
>
> -- 
> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://developers.videolan.org/lists.html
>

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html