[Pkg-mozext-maintainers] icedove-dev vs xulrunner-1.9.1-dev

[Mike Hommey]

On Mon, Apr 12, 2010 at 06:13:38PM -0400, Daniel Kahn Gillmor wrote:
> hello mozilla packagers:
> 
> i'm looking at ways of building architecture-dependent icedove
> extensions on debian using the new icedove-dev packages.
> 
> I notice that icedove-dev ships with many of the same files as
> xulrunner-dev, but in /usr/include/icedove instead of
> /usr/include/xulrunner-1.9.1

This isn't unexpected.

> possibly even more worrisome, some of the include files seem to
> differ slightly, even in the directories labeled "stable", e.g.
> HAVE_CPP_2BYTE_WCHAR_T is defined in icedove/stable/xpcom-config.h,

This should definitely be changed. I'm on my way for a better "fix" on
xulrunner that I hope will be applied to icedove. I'll come back later
with that.

> but undefined in xulrunner-1.9.1/stable/xpcom-config.h, and icedove
> has a few extra function defined for nsTArray.h, as well as an
> NS_RUNTIMEABORT() macro in nsDebug.
> 
> The above differences are present in stable/ when comparing
> icedove-dev 3.0.4-2 and xulrunner-dev 1.9.1.9-3.  There are even
> more pronounced differences in unstable/, or if you compare
> icedove-dev against xulrunner-dev 1.9.1.8-*.

This isn't unexpected.

> So i guess i'm wondering: for packages that need to compile against
> icedove headers, should the -I flags prefer /usr/include/icedove?

yes

> or $(pkgconfig --cflags libxul) ?  do we really want both sets of
> headers to exist on the system concurrently?

yes, see below.

> for that matter, i note that /usr/lib/icedove contains:
> 
>  libmozjs.so
>  libxpcom.so
>  components/libimgicon.so
>  components/libmozgnome.so
>  components/libdbusservice.so
> 
> all of which seem to have other versions available in
> /usr/lib/xulrunner-1.9.1 (or via libmozjs).
> 
> is this mini-"dll-hell" going to get us into trouble during the next
> release cycle?  Could it be avoided somehow?

Not until upstream changes things so that icedove can be built on top
of xulrunner.

Mike