mozilla-config.h is no longer in the SDK

RESOLVED INVALID

Status

RESOLVED INVALID
11 years ago
6 months ago

People

(Reporter: hello, Unassigned)

Tracking

Trunk

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
mozilla-config.h is in dist/include, but is not in dist/sdk/include.  In my objdir:

$ find . -name mozilla-config.h
./dist/include/mozilla-config.h
./mozilla-config.h

Comment 1

11 years ago
ok... why is this a problem? I think it was by design, because mozilla-config is an arch-dependent header and really ought not to be in an include/ directory at all...
(Reporter)

Comment 2

11 years ago
The header used to be there in previous versions of the SDK (in the root, though, not in include/), and there are defines in it that seem genuinely useful when building a binary component.

Also, we have documentation that mentions it:

http://developer.mozilla.org/en/docs/Creating_XPCOM_Components:Setting_up_the_Gecko_SDK

As well as outside tutorials that use it:

http://www.iosart.com/firefox/xpcom/

If not through mozilla-config.h, then how would you know which features the SDK you are linking to provides?

Comment 3

11 years ago
But... isn't mozilla-config.h still in the SDK? Just in a different place now?

It's not a frozen header, which is why it shouldn't be in dist/sdk
(Reporter)

Comment 4

11 years ago
I must be confused.  I thought objdir/dist/sdk contained all the files in the SDK, does it not?

How do I create the SDK, with all the files that need to go in it?

Comment 5

11 years ago
Not since we switched to the full-style SDK about 6 months ago... "make sdk" in a xulrunner tree will package the SDK for you, or you can just download the .sdk packages from http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-trunk/
(Reporter)

Comment 6

11 years ago
I am downloading one now to look at it.  I have a couple of questions:

* Do we guarantee the SDKs built from XULRunner will have no conflicting definitions (headers or otherwise) with Firefox?  In my case, I want my component to run on Firefox, so it doesn't feel right to use an SDK that is built from a different tree.

* Why does a browser build create objdir/dist/sdk at all?  If it is not meant to be used, then it's just confusing.

* Should the gecko SDK page on devmo point to the URL to the nightlies?  It currently only links to the gecko 1.8 SDK.

Let me know if I should file bugs for any of the above.

Comment 7

11 years ago
> * Do we guarantee the SDKs built from XULRunner will have no conflicting
> definitions (headers or otherwise) with Firefox?  In my case, I want my
> component to run on Firefox, so it doesn't feel right to use an SDK that is
> built from a different tree.

Well... they're built from the same sources. Not sure I understand the concern. This is really "the Mozilla platform SDK" which should be usable for all mozilla-based apps from a particular codebase.

> * Why does a browser build create objdir/dist/sdk at all?  If it is not meant
> to be used, then it's just confusing.

The dist/sdk directory contains only *frozen* headers and libraries. This distinction is maintained in the SDK package you download.

> * Should the gecko SDK page on devmo point to the URL to the nightlies?  It
> currently only links to the gecko 1.8 SDK.

You're welcome to add a link. Obviously we don't have "official" SDK packages for 1.9 since it hasn't shipped yet.
(Reporter)

Comment 8

11 years ago
(In reply to comment #7)
> > * Do we guarantee the SDKs built from XULRunner will have no conflicting
> > definitions (headers or otherwise) with Firefox?  In my case, I want my
> > component to run on Firefox, so it doesn't feel right to use an SDK that is
> > built from a different tree.
> 
> Well... they're built from the same sources. Not sure I understand the concern.
> This is really "the Mozilla platform SDK" which should be usable for all
> mozilla-based apps from a particular codebase.

My worry was really about mozilla-config.h in particular: that file contains build-time defines, which doesn't jive with the SDK as a cross-application kit.  e.g., the SDK has defines like MOZ_SVG 1, which maybe Firefox or some other app won't ship with.

I guess I'm actually just questioning the value of #including mozilla-config.h at all.  Why is it recommended in our documentation?

> > * Should the gecko SDK page on devmo point to the URL to the nightlies?  It
> > currently only links to the gecko 1.8 SDK.
> 
> You're welcome to add a link. Obviously we don't have "official" SDK packages
> for 1.9 since it hasn't shipped yet.

Done.

Comment 9

11 years ago
Applications are not supposed to pick and choose which gecko features they ship.

You *have* to include xpcom-config.h to pick up basic feature checks for the compiler. I don't think you have to include mozilla-config.h, but you might, and it's the safest route to getting the same environment that you would out of the mozilla build system.
(Reporter)

Comment 10

11 years ago
Okay, then I think the only problem is outdated documentation/tutorials floating around the web (for gecko 1.7).  Thanks for the explanation.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID

Updated

6 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.