Make build changes for the embedding SDK...

RESOLVED FIXED in mozilla1.3beta



Embedding: APIs
16 years ago
15 years ago


(Reporter: Chak Nanga, Assigned: hacker formerly known as


({embed, topembed-})

embed, topembed-
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)





16 years ago
Need to make the necessary build changes to the Mozilla build system in order to
be able to build an embedding SDK out of it.

More info. on the SDK and the currently proposed dir structure of of it is at :


16 years ago
QA Contact: mdunn → depstein
Severity: normal → critical
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla0.9.7

Comment 1

16 years ago
Hi Chris,

From our discussion last Wednesday, the one unresolved issue was that of the
format change to the current embedding manifest file.

Since you mentioned that you've got some ideas on the file format, it'd be a
great starting point (for discussion) if you could post it here.

I was just thinking about making basebrowser-* so that it would be rooted in
dist/sdk instead of dist/bin.  It would have relative paths for bin/*,
include/*, mre, etc.  I haven't really thought about it more than that.  I'm
more concerned about how to change the build system to use sdk at this point.

Comment 3

16 years ago
Hi All: Do we all agree with what Chris's thinking here. If yes, Chris can
proceed with this changes.

Hi Chris: The current target milestone we've got for the SDK is 0.9.7. Do you
think it can make that milestone


Comment 4

16 years ago
I'm fine with it
I do have to ask a question:  What's the actually embedding plan?  I've been
queried in several separate bugs asking if one patch or the other will help our
"embed" builds.  Are we planning on making a separate "embed" build that uses
all of these -DNO_XUL -DEDITOR_PLAINTEXT flags or are we sticking with our
current effort of restructuring the build around the embedding core so that the
libs used in the "embed" build are the same as the stock libs for the browser app?

Comment 6

16 years ago
well, NO_XUL is more of a compile-time flag to worry about. since
EDITOR_PLAINTEXT is more of a linking issue (right, akkana?) I'd say that we
have two issues:
1) Embedding as a compile-time issue - you can do a build with or without
embedding-related flags like NO_XUL
2) embedding as a link and packaging issue - after building, no matter what type
of binaries you end up with, you package only a subset of the dlls that are
actually built.

Now ultimately, #2 will go away, because you'll only build the modules that you

Not that us helps us figure out where we're going with this :)

Comment 7

16 years ago
I guess we're seeing a middle ground emerge.

Let's continue down the embed core model, which the "larger" mozilla general
build will leverage. However, I think we're going to want to do some compile
time #define #ifdef'ing (NO_XUL for example), which we should be able to do w/
the "embed" build. This assumes that the "embed" build can be done independently
of the full mozilla build (not the other way around though). If certain flags
are set  at build time, the full build may not succeed or may not run.
Depends on: 107301
Depends on: 107302
Priority: P1 → P2
Target Milestone: mozilla0.9.7 → mozilla1.0


16 years ago
Keywords: mozilla1.0


16 years ago
Keywords: topembed

Comment 8

16 years ago
how far off is this one?

Comment 9

16 years ago
I suspect this bug is a dupe or a meta bug at this point. mcafee just sent email
out about his latest hackery to some build scripts to do cvs pulls based on
REQUIRES dependency chains. seawood has a new toplevel build makefile that will
do selective module builds. AFAICT, we're close to merging the two, then we're
purely blocked on c++ dependency hammering which alec is whacking (he has many
bugs filed on broken dependencies). 

The goal is to get rid of the basebrowser-* manifest files in favor of the
configurable build.

Comment 10

16 years ago
topembed-, embed
keep working on this, for next relases

- triage team (chofmann, cathleen, marcia)
Keywords: topembed → embed, topembed-

Comment 11

16 years ago
we also need some status update on this, thanks.

- triage team
*** Bug 71164 has been marked as a duplicate of this bug. ***
Well, the 'make install' target from bug 56601 gives us a basic layout that's
MRE-compatible on unix.  The mozilla-config script was modified so that it would
search the $prefix/lib/mozilla-$version directory instead of $prefix/lib for
libraries.  Once we start actually putting libraries into the MRE directory, it
could be easily modified to search there as well/instead.  Minus some missing
headers (bug 149483), blizzard reported that it was possible to build galeon
with this setup.  I'm not sure if galeon is one of our test cases or even a true
embedding client (ie, only requires established embedding apis) though.

I'm still not comfortable with the SDK layout as shown at  I'm not sure
if it's my lack of familiarity with the JDK, the lack of specified MRE files or
the win32-centric nature of the diagram but something just doesn't sit right.  

Why do we have the extra bin/ under MOZ_SDK/mre ? Why is MOZ_SDK/lib just for
static libs? Or should that be labelled as development libs (ie, the stub libs
needed to link the app), which appear as static libs on win32 (.lib) but are .so
on unix.  

Dougt took the initiative and added SDK_* variables for xpcom to create a xpcom
sdk.  Are we planning on having each module to specify their variables in the
same fashion? I hope so because otherwise we're going to wind up with all of the
headers from dist.  The current SDK_* vars don't use the MRE layout so I may
have to hijack them.

Assignee: cls → seawood
Severity: critical → major
Priority: P2 → P3
Target Milestone: mozilla1.0 → Future

Comment 14

16 years ago
Hi Chris:

>I'm still not comfortable with the SDK layout as shown at

The only reason the MRE sub-directory's there under the SDK is because i
envisioned(similar to the JDK) that the users have something to test their apps
without having to download a separate runtime i.e. the MRE.

I'm open to other approaches as well. Here's what i think would be a great first
step towards SDK/MRE:
[The following steps also indicate how a typical Mozilla embeddor would develop
and deploy their embedding app]

1. We provide a mechanism for users to build their embedding apps without them
having to download the entire Mozilla source i.e. we provide just the SDK(minus
the MRE sub-dir as mentioned in the doc). They have everything they need to
embed Gecko into their apps - headers to include, libs to link against etc.

2. Assuming we have an embedding SDK, the user now has an embedding app built
against a certain version of Mozilla. To test (or to run) it, they need an MRE.

3. We provide them the MRE as a separate package using which they can test their
embedding apps built earlier. The MRE will be the dlls/so's needed to run an
embedding app. 

4. They deploy their app with the appropriate version of the MRE. If a
compatible version of the MRE is present they deploy just their application

Please see for more info on MRE

I can setup a meeting with the appropriate folks if this warrants further
discussion. What do you think?



15 years ago
QA Contact: depstein → ashishbhatt
I think all of the build changes are in.
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.3beta
You need to log in before you can comment on or make changes to this bug.