[vlc-devel] Re: Can't Build from Source, want to help with image filters/scaling and quality control
neil at woodall.occoxmail.com
Tue Feb 27 19:10:43 CET 2007
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
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
>> 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.
> 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
More information about the vlc-devel