XPCOM Standalone

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

XPCOM Standalone

Aaron M. Folmsbee
I would like to use xpcom (as its function and name suggests) as a
cross platform component api; an alternative to COM, CORBA, or a
custom C linkage API.

Various attempts at compiling xpcom, using different mozilla build
configuration incantations, have resulted in a xpcom library that
wants to link to gtk, xul, X, and a wide variety of other libraries,
none of which should be necessary for actually using the xpcom
technology.

Is it possible to build xpcom without the unnecessary dependencies? If
so how?

The goal is to have a xpcom library and the utilities (xpidl, etc..),
such that they can be used without any links (at the library level) to
mozilla at large, usable in a server environment. Ideally, support for
xpconnect and javascript (java, other languages as supported) would be
available as well.

At this point, I am ready to abandon any attempt to use xpcom, since
it does not seem to be independent enough, which is unfortunate.

Any help would be appreciated.

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

Myk Melez
[hidden email] wrote:
> Is it possible to build xpcom without the unnecessary dependencies? If
> so how?

I'm clueless on the subject, and the page is really old, but there's a
page that purports to explain how to build XPCOM standalone:

http://www.mozilla.org/projects/xpcom/xpcom-standalone.html

There are also other pages that might help.  Trying googling for
"standalone XPCOM".

-myk
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

Benjamin Smedberg
In reply to this post by Aaron M. Folmsbee
[hidden email] wrote:

> Is it possible to build xpcom without the unnecessary dependencies? If
> so how?

You could try to build with --enable-application=xpcom

and see what happens. I'm pretty sure nobody has tested it in a long time,
so you may need to hack the makefiles (and that's not easy).

> At this point, I am ready to abandon any attempt to use xpcom, since
> it does not seem to be independent enough, which is unfortunate.

Standalone XPCOM is not really a high priority goal. If people want to
maintain it, I'll accept patches (and even perhaps provide some clues on
IRC), but expect life to be a bit lonely.

--BDS
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

Aaron M. Folmsbee
On Feb 22, 9:00 am, Benjamin Smedberg <[hidden email]> wrote:

> [hidden email] wrote:
> > Is it possible to build xpcom without the unnecessary dependencies? If
> > so how?
>
> You could try to build with --enable-application=xpcom
>
> and see what happens. I'm pretty sure nobody has tested it in a long time,
> so you may need to hack the makefiles (and that's not easy).
>
> > At this point, I am ready to abandon any attempt to use xpcom, since
> > it does not seem to be independent enough, which is unfortunate.
>
> Standalone XPCOM is not really a high priority goal. If people want to
> maintain it, I'll accept patches (and even perhaps provide some clues on
> IRC), but expect life to be a bit lonely.
>
> --BDS

After taking a look at some of the xpcom makefiles, it would appear
the standalone build is possible. For the benefit of mankind, here is
the solution:

The original configuration produced an xpcom lib with xul dependency:
ldd obj-build/dist/lib/libxpcom.so
        libxul.so => not found
        ...

Building xpcom standalone:

cvs -d :pserver:[hidden email]:/cvsroot co -r
MOZILLA_1_8_BRANCH mozilla/client.mk
cd mozilla

.mozconfig
mk_add_options MOZ_OBJDIR=@topsrcdir@/obj-build
ac_add_options --enable-application=standalone
ac_add_option --disable-xul
ac_add_options --disable-javaxpcom
ac_add_options --enable-modules=xpcom
ac_add_options --enable-standalone-modules=xpcom

gmake -f client.mk checkout MOZ_CO_PROJECT=xulrunner
gmake -f client.mk build

 ldd lib/libxpcom.so
        libxpcom_core.so => not found

If anyone can suggest how it would be possible to build xpcom
standalone with javascsript as well, please let me know (I haven't
tried yet).

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

jonsmirl@gmail.com
On 22 Feb 2007 09:32:42 -0800, [hidden email] <[hidden email]> wrote:
> On Feb 22, 9:00 am, Benjamin Smedberg <[hidden email]> wrote:
> > [hidden email] wrote:
> > > Is it possible to build xpcom without the unnecessary dependencies? If
> > > so how?

xpserver used xpcom standalone and javascript integrated together.
You might be able to decode the makefiles from it.

http://xpserver.mozdev.org/


> >
> > You could try to build with --enable-application=xpcom
> >
> > and see what happens. I'm pretty sure nobody has tested it in a long time,
> > so you may need to hack the makefiles (and that's not easy).
> >
> > > At this point, I am ready to abandon any attempt to use xpcom, since
> > > it does not seem to be independent enough, which is unfortunate.
> >
> > Standalone XPCOM is not really a high priority goal. If people want to
> > maintain it, I'll accept patches (and even perhaps provide some clues on
> > IRC), but expect life to be a bit lonely.
> >
> > --BDS
>
> After taking a look at some of the xpcom makefiles, it would appear
> the standalone build is possible. For the benefit of mankind, here is
> the solution:
>
> The original configuration produced an xpcom lib with xul dependency:
> ldd obj-build/dist/lib/libxpcom.so
>         libxul.so => not found
>         ...
>
> Building xpcom standalone:
>
> cvs -d :pserver:[hidden email]:/cvsroot co -r
> MOZILLA_1_8_BRANCH mozilla/client.mk
> cd mozilla
>
> .mozconfig
> mk_add_options MOZ_OBJDIR=@topsrcdir@/obj-build
> ac_add_options --enable-application=standalone
> ac_add_option --disable-xul
> ac_add_options --disable-javaxpcom
> ac_add_options --enable-modules=xpcom
> ac_add_options --enable-standalone-modules=xpcom
>
> gmake -f client.mk checkout MOZ_CO_PROJECT=xulrunner
> gmake -f client.mk build
>
>  ldd lib/libxpcom.so
>         libxpcom_core.so => not found
>
> If anyone can suggest how it would be possible to build xpcom
> standalone with javascsript as well, please let me know (I haven't
> tried yet).
>
> _______________________________________________
> dev-tech-xpcom mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-xpcom
>


--
Jon Smirl
[hidden email]
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

Tavin
In reply to this post by Aaron M. Folmsbee
On Feb 22, 5:32 pm, "[hidden email]" <[hidden email]> wrote:
> After taking a look at some of the xpcom makefiles, it would appear
> the standalone build is possible. For the benefit of mankind, here is
> the solution:

i would like to see a standalone xpcom project, slightly decoupled
from mozilla or at least the browser.

i'd want to be able to compile a lightweight interpreter for use on
servers, as well as a lightweight interpreter linked to Gecko & GTK or
whatever that you could just point at a XUL file.  i know about
XULRunner but it is hardly lightweight..

i can't imagine why there wouldn't be a lot of community interest in
this.

i'd say with your post we have a good start on a HOWTO.

-tavin

_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

rkiddy@mozilla.com
Tavin wrote:

> On Feb 22, 5:32 pm, "[hidden email]" <[hidden email]> wrote:
>> After taking a look at some of the xpcom makefiles, it would appear
>> the standalone build is possible. For the benefit of mankind, here is
>> the solution:
>
> i would like to see a standalone xpcom project, slightly decoupled
> from mozilla or at least the browser.
>
> i'd want to be able to compile a lightweight interpreter for use on
> servers, as well as a lightweight interpreter linked to Gecko & GTK or
> whatever that you could just point at a XUL file.  i know about
> XULRunner but it is hardly lightweight..
>
> i can't imagine why there wouldn't be a lot of community interest in
> this.
>
> i'd say with your post we have a good start on a HOWTO.
>
> -tavin
>

I see an opportunity here to help the testing task. I am new to Mozilla
technologies but the XPCOM layer looks like a good place to stand and
reach down into other layers to test them.

I also see NSS and NSPR and it seems like having a component version,
READMEs that state the versions of dependencies relied on, and things
such as that could lead to some really good things.

If we ask what a well-defined standalone module looks like, what would
people say? My guess would be:

1) fetchability with client.mk with a MOZ_CO_PROJECT
2) buildability therefrom
3) some TLC for http://wiki.mozilla.org/XPCOM

Other things come to mind, but they can start from the wiki page.

- ray
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

Benjamin Smedberg
[hidden email] wrote:

> I see an opportunity here to help the testing task. I am new to Mozilla
> technologies but the XPCOM layer looks like a good place to stand and
> reach down into other layers to test them.

XPCOM is a good way to define API interfaces and test them, but I don't
think this means that *standalone* XPCOM will be useful for testing.

Most of our component have interdependencies in implementation; many
component require the networking stack to be available, for instance. Any
gecko component that is localizable ends up with a dependency on the chrome
registry, which has dependencies on the security system (CAPS).

I think that we should test and treat "the toolkit" as a monolith, which
includes XPCOM, networking, etc. For some thoughts on this, see
http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/

--BDS
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

rkiddy@mozilla.com
Benjamin Smedberg wrote:
> [hidden email] wrote:
>
>> I see an opportunity here to help the testing task. I am new to Mozilla
>> technologies but the XPCOM layer looks like a good place to stand and
>> reach down into other layers to test them.
>
> XPCOM is a good way to define API interfaces and test them, but I don't
> think this means that *standalone* XPCOM will be useful for testing.

You are right. XPCOM is a good way to define API interfaces and test
them. And it does not follow from that that a standalone XPCOM would be
useful. But I do believe a standalone XPCOM would be useful.

> Most of our component have interdependencies in implementation; many
> component require the networking stack to be available, for instance. Any
> gecko component that is localizable ends up with a dependency on the chrome
> registry, which has dependencies on the security system (CAPS).
>

Understood.

> I think that we should test and treat "the toolkit" as a monolith, which
> includes XPCOM, networking, etc. For some thoughts on this, see
> http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/
>

Yes, I had read that post. I do not agree with it, but I do have enough
experience with Mozilla specifically to reply with the same authority.

Simply put, though, there is an answer to the combinatorial interfaces
and configurations problem. The answer is found in specified component
interfaces and automated testing. I do not expect you to believe me on
this, right now. But it is what I believe.

There needs to be tests of XPCOM standalone and XPCOM not standalone,
and this can work if they are automated and the tests test the specified
component interfaces.

- ray
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

jonsmirl@gmail.com
On 2/24/07, [hidden email] <[hidden email]> wrote:
> There needs to be tests of XPCOM standalone and XPCOM not standalone,
> and this can work if they are automated and the tests test the specified
> component interfaces.

Long ago there was an effort made to make XPCOM standalone and
not-standalone the same identical binary and to get rid of all of the
IFDEFs. Did that work ever get finished?

During that long ago time the idea was to first compile and test XPCOM
standalone, NSPR and Spidermonkey in a standalone environment. Then
something like XULrunner would be compiled, tested and run on top of
this environment. I was quite in favor of this model since it greatly
reduces the scope of component interactions during the testing phase.
I never liked how Mozilla can only be compiled and tested as a single
giant blob (of course XULrunner is on the way to breaking things up).

There used to be a program around that built graphs of how all of the
modules in Mozilla called APIs between each other. It looked like a
giant bowl of spaghetti tied in a knot. Is it still around anywhere?

--
Jon Smirl
[hidden email]
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom
Reply | Threaded
Open this post in threaded view
|

Re: XPCOM Standalone

Christian Biesinger
In reply to this post by Tavin
Tavin wrote:
> On Feb 22, 5:32 pm, "[hidden email]" <[hidden email]> wrote:
>> After taking a look at some of the xpcom makefiles, it would appear
>> the standalone build is possible. For the benefit of mankind, here is
>> the solution:
>
> i would like to see a standalone xpcom project, slightly decoupled
> from mozilla or at least the browser.

Well, http://www.mozilla.org/projects/xpcom/xpcom-standalone.html has
some instructions. They may still work on the 1.8 branch, but probably
not on trunk. I still think it'd be kinda nice to make this work on trunk.

> i'd want to be able to compile a lightweight interpreter for use on
> servers, as well as a lightweight interpreter linked to Gecko & GTK or
> whatever that you could just point at a XUL file.  i know about
> XULRunner but it is hardly lightweight..

XPCOM itself isn't anywhere close to "Gecko"...




--
All the world's a stage,
And all the men and women merely players:
They have their exits and their entrances;
And one man in his time plays many parts, [...]     --W. Shakespeare
_______________________________________________
dev-tech-xpcom mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-xpcom