Closed Bug 140034 Opened 18 years ago Closed 17 years ago
RFE: about:buildinfo -- displays 'build options' used
about:buildinfo (type this in the address bar) displays - 'build options' that has been used at the time of building the current running software - 'build number' (same as the title bar) - date/time that it has been built - other related info these will help a lot for testing :)
To build config.
Assignee: Matti → seawood
Component: Browser-General → Build Config
QA Contact: imajes-qa → granrose
Yep, it would be nice though I'm not sure if we need to bloat the app with that info. Regardless, I have no idea how to plug this into the about: handler so it's going to be put off for a bit.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4
Target Milestone: --- → mozilla1.2alpha
Belongs in "about:", surely. As fine print under the current listing of the User-Agent. It can be put in as 'fine print' that the nontechnical user's eyes will fall off and ignore ;-)
Target Milestone: mozilla1.2alpha → Future
This should cover the basics.
Target Milestone: Future → mozilla1.4alpha
Attachment #113328 - Flags: review?(bbaetz)
Comment on attachment 113328 [details] [diff] [review] v1.0 + CC_VERSION=`$CC --version` That gives me: gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. which is a bit long.. We probably want -dumpversion instead, or pass it through sed, or soemthing. I dont' know how far -dumpversion goes back. If you do that, then you need to add 'GCC' in there somewhere What if that option doesn't exist? Won't configure exist with an error codeif teh backticks fail? More importantly, you need to html-escape the stuff in the html file. I also don't see somewhere which triggers the .in file to be seen by configure. It is possible for --version to have < or > in it. The HTML should also become valid, have a doctype added, and so on.
Attachment #113328 - Flags: review?(bbaetz) → review-
I tested with gcc 2.95.2 which just returns 2.95.2 for --version. 2.96 just returns 2.96 as well. --version is only used inside the $GCC = "yes" & $GXX = "yes" blocks so it wouldn't fail unless gcc stopped supporting it. Otherwise, CC_VERSION & CXX_VERSION default to 'N/A'. buildconfig.html is listed in allmakefiles.sh. That's how configure.in sees it and knows to generate it. What needs to be escaped? I don't plan to have all of that extra copyright info from the --version output. At most, it will be the first line which contains the binary name (GCC) version number and maybe the vendor variant. Bleh. What's "invalid" about the HTML other than the missing doctype declaration?
I missed the allmakefiles.sh change That block of text is what gc-3.2 prints out for --version, though, so it needs to be adjusted. I have this vague recollection of that being an annoucnced change somewhere, but ICBW. You have whole lot of <P> tags, with no </P>, or any content between that and the beginning of the following <hN>
Use '$CC -v' output containing 'gcc version' instead of --version. Let composer generate buildconfig.html.in so html should be valid.
Attachment #113328 - Attachment is obsolete: true
Comment on attachment 113873 [details] [diff] [review] v1.1 r=bbaetz if you change the <td><strong> stuff to use <th> instead.
Attachment #113873 - Flags: review+
* Changed <td><strong> to <th>
Attachment #113873 - Attachment is obsolete: true
Attachment #113879 - Flags: superreview?(darin)
Comment on attachment 113879 [details] [diff] [review] v1.2 looks fine to me (sr=darin)
Attachment #113879 - Flags: superreview?(darin) → superreview+
Patch has been checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.