71164 - SDK for embeddors

Status: VERIFIED DUPLICATE of bug 105289

(SeaMonkey :: Build Config, defect, P5)

Description

[Guy Alfandary]

This would allow embeddors test thier applications without
having to actually build the package themselves.

Comment 1

[cls]

Any ideas on how to go about this?  Dumping all of dist/include sounds like a
recipe for disaster (unpublished APIs out the whazoo).

Comment 2

[Christopher Blizzard (:blizzard)]

We need to label the header files as public or private and make a real export
list. It's grunt work and review work.

Comment 3

[Guy Alfandary]

Also include libembed_base_s.a or move the functionality therein
to one of the packaged libraries.

Comment 4

[cls]

The work may fall into the less-brain consuming tasks category but I don't think
just any grunt can do it.  By marking these headers as public/private, we'll be
defining an API. Not frozen by any means but an API nonetheless.  Perhaps
someone who's actually been following the API review meetings should be handling
this.

I'd be willing to add RELEASE_HEADERS that is adjunct to EXPORTS and will cause
the selected headers to be installed into dist/include/released or something. 

Comment 5

[Judson Valeski]

48726 - covers "freezing" api's via tokens in idl files themselves. An "SDK"
(binary dist, full docs, frozen apis) as a package, is 12+ months away. Bug,
70229 is a meta bug covering a massive TODO list for freezing apis.
http://www.mozilla.org/projects/embedding/apiReviewNotes.html covers public api
discussion.

Chris, if you'd like, I can take this bug. Everyone should note that an
embedding SDK is akin (sp?) to saying "Mozilla should release a 1.0 browser."
There's a lot more than a "SDK for embeddors" bug that comes into play (see
70229, and that's *just* the API piece - *nothing* bug api changes should be in
that meta bug). We have tons of build/dist issues to overcome.

Comment 6

[Guy Alfandary]

You want people to test your embedding API's. Why not help them
doing so by including the necessary resources (headers & embed lib)
in the package? This seems like 30 min. of work at the outside.
The only difference it would make is that embeddors won't have
to keep building the whole package themselves. We already
have access to all this stuff, why not save us some work?

Comment 7

[Guy Alfandary]

At 1.0 this would be useless to us.

Comment 8

[Judson Valeski]

maybe for you, but not others. re-opening.

Comment 9

[Winnie Lam]

minusing to topembed- and adding embed as per edt triage.  a *very* nice to have
but not blocking a particular embedding customer.

Comment 10

[hacker formerly known as [e-mail]]

*** This bug has been marked as a duplicate of 105289 ***

Comment 11

[Jon Granrose]

v dup.