If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[META] make xpcom independent standalone project

RESOLVED WONTFIX

Status

()

Core
XPCOM
--
enhancement
RESOLVED WONTFIX
14 years ago
5 years ago

People

(Reporter: cls, Unassigned)

Tracking

({meta})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
xpcom should be an independent standalone project.  There are several
applications using it outside of the Mozilla/gecko realm and we should make it
easier for those projects to use xpcom.  Having to pull all of Mozilla or hoping
that --enable-standalone-modules works correctly is a bit daunting for a
non-mozilla developer. 

Before we can make the build changes required to make xpcom standalone, there
are some issues that must be cleared up first.  Most of these were covered by
the reorg proposal and postmortem.

* Fix issue of differing symbols in debug & opt builds (bug 211534)
* Do not expose implementation details via headers (bug 210409)
* Do not generate (unnecessary) chrome files (bug 214690)
* Move string & libreg under mozilla/xpcom/ (bug 214700)
* Reuse the existing common build makefiles
* Create new xpcom/configure.in (bug 214701)
* Hook new configure.in into mozilla/client.mk & mozilla/configure.in

Some serious thought needs to be given to an independent versioning scheme as
well.  As an independent project, xpcom should not be relying upon the
Mozilla/Firebird/GRE versioning scheme.  (We'll deal with the soversioning
problem later.)

Comment 1

14 years ago
I like it. :-)

* Move string & libreg under mozilla/xpcom/ (bug 214700)
  libreg should move to mozilla/xpcom/obsolete

versioning will be a problem.  Hopefully, we can get around some of the woes by
only stating the symbols that will not change between version.  That is, ensure
compatiblity by saying you can only link against xpcom for symbols X, Y, Z. 
That was the general direction i was moving in....  

This isn't going to be an easy task.  Gecko currently know too much about the
impl. detials of XPCOM.  

Maybe we should think about what parts of XPCOM should be broken out into a
frozen library?
(Reporter)

Updated

14 years ago
Depends on: 218777

Comment 2

11 years ago
Created attachment 227037 [details] [diff] [review]
remove MOZ_WIDGET_TOOLKIT

To build xpcom as standalone project we must not use MOZ_WIDGET_TOOLKIT variable.

Comment 3

11 years ago
Comment on attachment 227037 [details] [diff] [review]
remove MOZ_WIDGET_TOOLKIT

or just defined MOZ_WIDGET_TOOLKIT during the build.

Comment 4

11 years ago
> or just defined MOZ_WIDGET_TOOLKIT during the build.
This variable used for OS type determination. We have OS_ARCH for this goal.
(Reporter)

Comment 5

11 years ago
Comment on attachment 227037 [details] [diff] [review]
remove MOZ_WIDGET_TOOLKIT

Don't clutter the meta bug with these specific issues.  This particular topic is already being covered by bug 313780.  Btw, this patch assumes Darwin == OSX and breaks the Darwin/X11 builds.
Attachment #227037 - Flags: review-
Assignee: dougt → nobody
QA Contact: scc → xpcom

Comment 6

5 years ago
A thousand times no thanks.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.