This would allow embeddors test thier applications without having to actually build the package themselves.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Target Milestone: --- → mozilla0.9
Any ideas on how to go about this? Dumping all of dist/include sounds like a recipe for disaster (unpublished APIs out the whazoo).
We need to label the header files as public or private and make a real export list. It's grunt work and review work.
Also include libembed_base_s.a or move the functionality therein to one of the packaged libraries.
Summary: Include header files in nightly builds → SDK for embeddors
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.
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.
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?
At 1.0 this would be useless to us.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
maybe for you, but not others. re-opening.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
minusing to topembed- and adding embed as per edt triage. a *very* nice to have but not blocking a particular embedding customer.
Keywords: topembed → embed, topembed-
*** This bug has been marked as a duplicate of 105289 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.