296426 - nsIXULRuntime should provide selected build config info

Status: RESOLVED FIXED

(Toolkit Graveyard :: XULRunner, enhancement, P4)

Description

[Jens Bannmann]

There should be a way to programmatically access some parts of the build config.
Most importantly, these are OS_TARGET and TARGET_ABI, the latter being
introduced by bug 294835. bsmedberg proposed adding these to nsIXULRuntime.

In case we don't have exact knowledge about the compiler being used, TARGET_ABI
won't be set - the corresponding property should then just be null.

Comment 1

[Jens Bannmann]

Robert, I noticed that Reporter parses about:buildconfig to get the configure
arguments. I thought it might be a good idea to have a less fragile way of
accessing these (and to use the current method as a fallback for old builds). I
propose adding a property to the nsIXULRuntime interface that holds these
arguments. If you agree, you'd only have to convince bsmedberg that it's
valuable enough to be included...

Comment 2

[Darin Fisher]

I think this is a good idea too.  Right now, people end up having to grok
similar information from nsIHttpProtocolHandler, and that is not such a great
solution.

Comment 3

[Benjamin Smedberg]

Attachment: Add nsIXULRuntime.OS and XPCOMABI

I decided not to do .getFeature for this because it seems like overkill and I
really don't intend to freeze this any time soon.

Comment 4

[Darin Fisher]

Comment on attachment 185811 [details] [diff] [review]
Add nsIXULRuntime.OS and XPCOMABI

Looks ok, but I'd probably make XPCOMABI only expose the value of
TARGET_XPCOM_ABI since the combined value could then be formed from OS and
XPCOMABI.  plus it is confusing that XPCOMABI != TARGET_XPCOM_ABI.

Comment 5

[Jens Bannmann]

I second Darin's suggestion of XPCOMABI = TARGET_XPCOM_ABI. In fact, that is the
way I had implemented it. Both variables should just represent the configure
variables.

Oh, is there a reason for making these attributes ALLCAPS and not mixedCase? I'd
simply go for "xpcomABI" and "osTarget"... The latter is especially nice because
the name alone already emphasizes on *which* of our countless OS-related
configure vars it is based, e.g. not TARGET_OS.

Comment 6

[Darin Fisher]

bsmedberg and I talked about how to name these things, and we decided that
XPCOMABI is the best choice because it is afterall an acronym.

Comment 7

[Benjamin Smedberg]

Attachment: Add nsIXULRuntime.OS and XPCOMABI, rev. 2 [checked in]

Make XPCOMABI just <processor>-<compilerABI> per review, carrying over review.

Comment 8

[Benjamin Smedberg]

Comment on attachment 185854 [details] [diff] [review]
Add nsIXULRuntime.OS and XPCOMABI, rev. 2 [checked in]

Checked XPCOMABI revision 2 in, leaving this bug open for possible inclusion of
configure args as a propertybag.

Comment 9

[Jens Bannmann]

nsIHttpProtocolHandler is also the only way to determine the Gecko revision (via
a substring of the "misc" portion of the UA string). What do you all think,
should we include that in nsIXULRuntime as well? I think it could improve
version distinction in extensions (especially when interfaces change), and it
would be nice to have it as a separate, well-documented attribute.

Comment 10

[Darin Fisher]

nsIXULAppInfo.geckoBuildID reports the datestamp of the Gecko build, but it does
not report the version.  I agree that the Gecko version should be exposed
someplace on this object.  Maybe both should be on nsIXULRuntime.

Comment 11

[Robert Accettura [:raccettura]]

the reporter tool is a consumer of all done so far (and future todo's).  

Currently I am using a mess of code to pull the buildconfig string out of
about:buildconfig.  A more reliable method would obviously be welcome.  The
method we are doing right now is somewhat fragile (if buildconfig's html were to
change were busted).  

I'm not sure how much use it would be to others.  But I would be able to make
good use of a better method.

Comment 12

[Benjamin Smedberg]

The remaining bits of this bug are not 1.8 material.

Comment 13

[Jens Bannmann]

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

Comment 14

[Benjamin Smedberg]

Marking this fixed. If somebody wants configure flags as a propertybag they may use a separate bug.