731121 - nsIProxyObjectManager.h no longer installed, destroys ability to compile pyxpcom

Status: VERIFIED INVALID

(Core :: General, defect)

Description

[lkcl]

User Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB) AppleWebKit/534.3 (KHTML, like Gecko) Arora/0.10.1 Safari/534.3

Steps to reproduce:

build mozilla-central xulrunner 13.0a1 and pyxpcom


Actual results:

make[6]: Entering directory `/home/lkcl/oe/src/gecko/pyxpcom-9.0~hg20111212/builddir/xpcom/src/module'
_xpcom.cpp
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

Comment 1

[Boris Zbarsky [:bzbarsky]]

There is no such file, so it can't possibly be installed.

In fact, there are no more XPCOM proxies, hence no proxy object manager.  See bug 675221.

Comment 2

[lkcl]

boris, that leaves me with absolutely no information!  the file _does_ exist, btw.

is this something to do with nsCOMPtr?  i am guessing here because, again, decisions have been made to change interfaces whilst leaving pyxpcom completely outside of the day-to-day compilation.

i see ten occurrences of the use of nsCOMPtr templated variables, but i have absolutely _no_ idea what to do here.

i'm therefore re-opening this bug, and would appreciate advice on each and every one of the functions which need replacements for nsCOMPtr.

let's start with this one: PyXPCOMMethod_GetComponentManager.  what is supposed to happen, here?


// "boot-strap" methods - interfaces we need to get the base
// interface support!

static PyObject *
PyXPCOMMethod_GetComponentManager(PyObject *self, PyObject *args)
{
    if (!PyArg_ParseTuple(args, ""))
        return NULL;
    nsCOMPtr<nsIComponentManager> cm;
    nsresult rv;
    Py_BEGIN_ALLOW_THREADS;
    rv = NS_GetComponentManager(getter_AddRefs(cm));
    Py_END_ALLOW_THREADS;
    if ( NS_FAILED(rv) )
        return PyXPCOM_BuildPyException(rv);

    return Py_nsISupports::PyObjectFromInterface(cm, NS_GET_IID(nsIComponentManager), PR_FALSE);
}

Comment 3

[lkcl]

actually... no, wait: that explains why nsIProxyObjectManager.h didn't actually exist for some time.

i've been going back through the history doing spot-checks and recompilations: several builds didn't actually even compile (dates around dec).

but builds at least after 19th jan until now *do* build nsIProxyObjectManager.h - but it's just not copied out of the source code into /usr/..../include/xulrunner-NN.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> boris, that leaves me with absolutely no information!

What information are you looking for?

> the file _does_ exist, btw.

http://mxr.mozilla.org/mozilla-central/find?text=&kind=text&string=nsiproxyob disagrees.

So does the patch in bug 675221.  The file was removed as of XULRunner 12.  You're building against 13.

The function you pasted doesn't use the proxy object manager that I can see, of course.

I'm going to stop wasting my time on this....

Comment 5

[Josh Matthews [:jdm]]

Please read the first paragraph at https://developer.mozilla.org/en/nsISupports_proxies, and follow the link therein for a document on how to replace existing uses of XPCOM proxies.

Comment 6

[lkcl]

ok, rrright: in amongst a massive amount of *additional* changes in a multi-purpose attachment/patch, in amongst 10 associated patches, i find that there are 10 lines out of 500 that _actually_ do the job of removing the references to nsIProxyObjectManager and associated code.

it's about 2/5ths the way through this:
https://bugzilla.mozilla.org/attachment.cgi?id=549390&action=edit

so, i assume - and it is merely an assumption - that simply commenting out the references to ProxyObjectManager in _xpcom.cpp will suffice.

i have no idea however if there are changes required of the order of magnitude that were also carried out as part of bug #675221.

perhaps if someone could confirm that such extensive similar changes are needed, or not?

thanks.

Comment 7

[lkcl]

thanks matt - bit of crossover here.  ok, do you mean this?
https://developer.mozilla.org/en/XPCOM/Making_cross-thread_calls_using_runnables

if so, is this something that pyxpcom, which is merely middleware, needs to worry about?

does pyxpcom need to create a python-middleware-ish version of "cross thread calls using runnables"?

i don't know - as i am an outsider who has not been involved in the decision-making process i have absolutely no idea what is involved, so i am forced to ask questions that cover ground which other people who have more experience in this could have dealt with much quicker.

Comment 8

[lkcl]

(In reply to Boris Zbarsky (:bz) from comment #4)
> > boris, that leaves me with absolutely no information!
> 
> What information are you looking for?

 i don't know!  if i knew what i was doing i would ask! :)

> > the file _does_ exist, btw.
> 
> http://mxr.mozilla.org/mozilla-central/
> find?text=&kind=text&string=nsiproxyob disagrees.
> 
> So does the patch in bug 675221.  The file was removed as of XULRunner 12. 
> You're building against 13.

 ok what i'm doing is i'm doing a binary-search on the mozilla-central builds between dec and feb to find at least _one_ revision of the code that actually works.

 it's a standard technique for finding bugs which should have been dealt with, but have been entirely missed.

 unfortunately i'm running into a ton of other bugs along the way.

 
> The function you pasted doesn't use the proxy object manager that I can see,
> of course.
> 
> I'm going to stop wasting my time on this....

 sorry, boris - it looks like a "waste of time" but you can see from comment 6 (crossover) that i _did_ look in the bugreport that you referenced, but there was so much other crud and attachments that i didn't know what i was looking at - or for.

 i _did_ find some nsIProxyObjectManager functions commented out - but it was in amongst other functions that i have no idea what they are for (see comment 6)

 if you are feeling frustrated at this process, then i apologise: pyxpcom should never have been moved out of mozilla-central, and now "everyone's time is being wasted" as someone - me - who is completely unfamiliar with the code has to try to learn the mozilla codebase and "waste everybody's time" in the process, trying to get the code back up-and-running.

in other words i'm trying to do two things: 1) get the code fixed 2) demonstrate to the mozilla foundation that abandoning code that is actually in use is a bad idea.

so if you'd like to help - and you have been extremely helpful - but do not want your "time wasted" - just as much as *i* do not want my "time wasted", please help by pressurising the people who made the decision to abandon pyxpcom to get it *back* into mozilla-central and to run standard daily builds.

so that peoples' time is "not wasted", 6 months after the information about why particular decisions were made drops out of everybody's heads.

Comment 9

[Josh Matthews [:jdm]]

(In reply to lkcl from comment #7)
> thanks matt - bit of crossover here.  ok, do you mean this?
> https://developer.mozilla.org/en/XPCOM/Making_cross-
> thread_calls_using_runnables
> 
> if so, is this something that pyxpcom, which is merely middleware, needs to
> worry about?
> 
> does pyxpcom need to create a python-middleware-ish version of "cross thread
> calls using runnables"?
> 
> i don't know - as i am an outsider who has not been involved in the
> decision-making process i have absolutely no idea what is involved, so i am
> forced to ask questions that cover ground which other people who have more
> experience in this could have dealt with much quicker.

Yes, I do mean that link. I have no idea what changes you need to make, having never looked at PyXPCOM. However, if PyXPCOM is attempting to use the proxy object manager header, it's a reasonable guess that it's also attempting to use XPCOM proxies. If that's the case, it should use the technique described in that wiki link in place of each proxy it attempts to create.

Comment 10

[lkcl]

(In reply to Josh Matthews [:jdm] from comment #9)

> Yes, I do mean that link. I have no idea what changes you need to make,
> having never looked at PyXPCOM. However, if PyXPCOM is attempting to use the
> proxy object manager header, it's a reasonable guess that it's also
> attempting to use XPCOM proxies. If that's the case, it should use the
> technique described in that wiki link in place of each proxy it attempts to
> create.

 josh, it looks to be the case that pyxpcom merely "publishes" the proxy object manager function, nothing more.

 having removed the function, the rest of pyxpcom compiles happily.