Google Groups

Re: The future of binary embedding


lkcl luke Feb 29, 2012 4:30 PM
Posted in group: mozilla.dev.embedding
https://bugzilla.mozilla.org/show_bug.cgi?id=731121

where is the information required to fix this problem?

also, why was pyxpcom excluded from the update.... my god this was _months_ ago!
https://bugzilla.mozilla.org/show_bug.cgi?id=675221

why was pyxpcom not included in that update, when the information was
fresh in everyone's minds??

oh i know - because pyxpcom has been relegated to third party status.

ok.

how is this going to get fixed? (a so that this stops happening b
these specific coding errors so i can get some working code)


On Tue, Feb 28, 2012 at 6:05 AM, lkcl luke <luke.l...@gmail.com> wrote:
> the policy of relegating pyxpcom to "third party status" within the
> mozilla codebase has resulted in these kinds of things, below.
>
> you will recognise this as the consequences of a decision some time in
> the past few weeks (which i wasn't party to, because i am an
> "outsider" having no funds or time to pay 24x7 attention to each and
> every decision made by the people who _are_ funded by the mozilla
> foundation)
>
> basically that decision looks like it involved deliberate splitting of
> the header files into "public api" and "not public api".
>
> so, this header file nsIProxyObjectManager.h is treated as "internal api"...
>
> ... but somebody forgot that pyxpcom needs it... because they have
> relegated pyxpcom to "third party status".
>
> they forgot that pyxpcom *needs* to be built as an "internal"
> component, yet the mozilla foundation has completely failed to provide
> a system for building such components, yet at the same time has
> basically dumped the responsibility onto other people.
>
> if however pyxpcom was actually part of mozilla-central, then not only
> would this problem simply not be present but also it would be a damn
> sight easier to find issues.
>
> temporarily i am forced to manually seek out, copy and make available
> this "nsIProxyObjectManager.h" file each and every damn time i do a
> rebuild and reinstall of a particular version of the xulrunner
> runtime.
>
> that's incredibly tiresome and it's part of the *additional* burden
> that the mozilla foundation's decisions are placing onto external
> developers.
>
> ... developers that are *not* funded by the mozilla foundation, it's
> worth once again pointing out.
>
> right now i cannot agree more that the OLPC team made the right
> decision to remove all mozilla-foundation-funded technology from their
> machines.
>
> l.
>
> c++ -o _xpcom.o -c -I../../../dist/system_wrappers -include
> ../../../../config/gcc_hidden.h -DOSTYPE=\"Linux2.6\" -DOSARCH=Linux
> -DMOZ_NO_MOZALLOC -I/usr/include/python2.7
> -I../../../../xpcom/src/module -I. -I../../../dist/include
> -I../../../dist/include/nsprpub
> -I/usr/local/lib/xulrunner-devel-13.0a1/include
> -I/usr/local/lib/xulrunner-devel-13.0a1/include/nsprpub
> -I/usr/include/nspr          -fPIC   -fno-rtti -fno-exceptions -Wall
> -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
> -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
> -Wno-long-long -pedantic -DXULRUNNER_13_0A1 -std=gnu++0x -fshort-wchar
> -fno-strict-aliasing -pipe -std=gnu++0x  -DNDEBUG -DTRIMMED -Os
> -freorder-blocks -fno-reorder-functions    -DMOZILLA_CLIENT -include
> /usr/local/lib/xulrunner-devel-13.0a1/include/mozilla-config.h
> -Wp,-MD,.deps/_xpcom.pp ../../../../xpcom/src/module/_xpcom.cpp
> ../../../../xpcom/src/module/_xpcom.cpp:68:35: fatal error:
> nsIProxyObjectManager.h: No such file or directory
> compilation terminated.