105289 - Make build changes for the embedding SDK...

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: APIs, defect, P3)

Description

[Chak Nanga]

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 :
http://www.mozilla.org/projects/embedding/EmbeddingSDKSpec.html

Comment 1

[Chak Nanga]

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.

Thanks
Chak

Comment 2

[hacker formerly known as [e-mail]]

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

[Chak Nanga]

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

Thanks

Comment 4

[Alec Flett]

I'm fine with it

Comment 5

[hacker formerly known as [e-mail]]

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

[Alec Flett]

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
need....

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

Comment 7

[Judson Valeski]

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.

Comment 8

[chris hofmann]

how far off is this one?

Comment 9

[Judson Valeski]

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

[Cathleen]

topembed-, embed
keep working on this, for next relases

- triage team (chofmann, cathleen, marcia)

Comment 11

[Cathleen]

we also need some status update on this, thanks.

- triage team

Comment 12

[hacker formerly known as [e-mail]]

*** Bug 71164 has been marked as a duplicate of this bug. ***

Comment 13

[hacker formerly known as [e-mail]]

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
http://www.mozilla.org/projects/embedding/EmbeddingSDKSpec.html.  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.

Comment 14

[Chak Nanga]

Hi Chris:

>I'm still not comfortable with the SDK layout as shown at
http://mozilla..../EmbeddingSDKSpec.html

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
executable.

Please see http://www.mozilla.org/projects/embedding/MRE.html for more info on MRE

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

Thanks
Chak

Comment 15

[hacker formerly known as [e-mail]]

I think all of the build changes are in.