Bootstrapping libav on a new architecture

[Thorsten Glaser]

Fabian Greffrath dixit:

> and friends" the OP meant "library packages built from libav sources" in
> general.

Yes.

> Thorsten, that's three circular build-dependencies. Which one is the fourth one
> that you mentioned in your report?

frei0r, via some corners, too.

> Anyway, all of these codecs are optional. So if you comment out the B-Ds on
> libx264-dev, libopencv-dev and libcv-dev in debian/control and remove the
> "--enable-libopencv" line in debian/confflags, libav should build just fine and
> be available for bootstrapping of other packages.

OK, thanks. That’s what I figured, but you know the build system
best, and asking rarely hurts.


Reinhard Tartler dixit:

>Well, I take that as another reason to use the cond_enable macro in
>debian/confflags for these libraries, because this way you do not even
>have to edit any file, but can just bootstrap with 'dpkg-buildpackage
>-d -b'.

That would be really cool. On the other hand, that may introduce
subtle breakage in normal operation, so many packages protect
something like that by using DEB_STAGE (if it’s set, gcc even has
DEB_STAGE=stage{1,2} checks as it needs them, then the relaxed
rules apply, otherwise the dependencies are strictly enforced).


Fabian Greffrath dixit:

> Maybe we should leave a note in README.Debian or README.source stating that
> there are known circular build-dependencies that complicate bootstrapping, but
> that the affected codecs are strictly optional to libav and the circles could
> get forced open by simply leaving them out of libav's Build-Depends.

And that would dot the i ;-)

Thanks,
//mirabilos • almost got hppa, now to tackle the automoc issue…
		http://buildd.debian-ports.org/stats/graph2-week-big.png
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr