497969 - It should be possible to identify which changeset libmozjs.so was built from

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, enhancement)

Description

[Wesley W. Garland]

Attachment: Patch to insert hg changeset into jsapi

My use-case for this feature is that I want to use it to invalidate my compiled byte-code cache (XDR frozen) when I push a new substantially new libmozjs.so.

Additionally, I would like to be able to query libmozjs.so and find out what micro-version it is for defect tracking, etc.

This patch addresses both those issues by providing an API which which returns the hg changeset as a const char *, and burying an unused string in jsapi.o which can be queried via RCS's ident(1).

The browser has this information already, in about:buildconfig, so this needn't ever affect anything other than jsapi embedders who want it.

Calling hg in the middle of a Makefile does not introduce any new dependencies and degrades gracefully; see similar build rule in http://mxr.mozilla.org/mozilla-central/source/toolkit/content/Makefile.in#61

Comment 1

[Brendan Eich [:brendan]]

What's the point of JSXDR_BYTECODE_VERSION if you need this? Seems like overkill. Hardly any changeset touches XDR format.

/be

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Doesn't this add a dependency on hg?  We don't require it to build today, and lots of people build from tarballs or rebuild distro packages, etc.

Comment 3

[Wesley W. Garland]

@Brendan: I was bit by invalid XDR just last week.  I don't know what the changes that caused the bytecode to be invalid (I just blew away the cache to resolve), but I'll double check that our loader is in fact checking JSXDR_BYTECODE_VERSION as I asked.

That's still a separate issue than being able to answer the "what libmozjs.so is this?" question.  Traditionally, I've used cvs/rcs $Id:$ for this problem, but that doesn't work with hg.  (Recording changesets is far superior to file versioning anyway)

@Shaver: This degrades to -DSOURCE_CHANGESET="" just as it does for the browser's about:buildconfig.

So, an API user that didn't build from hg will not get useful information from JS_GetSourceRepositoryIdentifier(); I think that's reasonable, although maybe a better return value could be suggested.  If it were up to me, I'd document this function as "If it returns an empty string, it is the official Mozilla SpiderMonkey distribution described by JS_GetImplementationVersion()"

Comment 4

[Jim Blandy :jimb]

Comment on attachment 383005 [details] [diff] [review]
Patch to insert hg changeset into jsapi

The patch to js/src/Makefile.in adds an extra 'endif'.

It seems to me that jsapi.o will only get rebuilt when an update changes the text of jsapi.cpp or headers it includes.  If an update affects only, say, jsobj.o, don't we end up with a stale source repository identifier?  I think we need one of these dependency-on-stamp-file maneuvers here.

In my copy of hg, hg identify's '-r' option takes a revision argument; your patch supplies '.'.  It seems to me you want to omit '-r' altogether, and get an id for whatever happens to be there.  Did I miss the intent here?

Wouldn't 'hg identify -i' give you the string you're looking for, without the 'cut'?

Should the declaration of JS_GetSourceRepositoryIdentifier use '(void)' instead of '()', since it is in an 'extern "C"' block?

Comment 5

[Wesley W. Garland]

jimb:

re. deps -- Rather than generating another object file, what do you think about marking jsapi.o as either a :: or a .PHONY target to make sure its run each time?

As for the difference between revision-checking commands, I have to admit, I'm not 100% up the on the subtleties of the semantics between them, but the performance difference is staggering on one of my (very very very slow) boxes: 

[~/hg/tracemonkey] wes:wes# /bin/time hg identify -r .
95d633a94459 tip

real        3.6
user        3.1
sys         0.3
[~/hg/tracemonkey] wes:wes# /bin/time hg identify -i
95d633a94459+

real       36.3
user        5.3
sys         5.0

I believe the difference is that -i has to traverse the repository looking for changes to figure out if it needs to put a plus after the identifier, where as -r . just gets the base revision id.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

FWIW, MOZ_SOURCE_STAMP uses:

hg -R $(topsrcdir) parent --template="{node|short}\n" 2>/dev/null

(see 515792, bug 536173)

Comment 7

[Wesley W. Garland]

Good call, Gavin; that's twice as fast (user, sys and wall clock) as hg identify -r. -- and avoids the need to run cut.