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

[Neil Woodall]

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