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 <[email protected]> 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. _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
