add Version tab on win32 DLLs/EXEs when viewing Properties

VERIFIED FIXED in mozilla1.0


20 years ago
15 years ago


(Reporter: bugzilla, Assigned: asasaki)



Windows 98
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt1])


(1 attachment, 11 obsolete attachments)



20 years ago
It should be possible to right-click on all installed DLL, EXE files in the
Mozilla directory and select Properties -> Version.


20 years ago
Severity: normal → enhancement
Summary: Version tab on all files when rightclicking on them and pressing Properties → add Version tab on win32 DLLs when viewing Properties
Target Milestone: M15


20 years ago
QA Contact: cyeh → cpratt

Comment 1

20 years ago
Changing QA Contact to self.

Comment 2

20 years ago
cc'ing cyeh since we talked about this bug last week.

Comment 3

20 years ago
reassigning to me. setting to M14. setting severity to normal. we need this 
before we ship. might not make it in time for beta1, but must be there for 

ccing ssu,

Leaf, we're probably going to have to hack deep in the bowels of the Win32 
config to add a default .rc file to be linked in with every dll and component.

Assignee: granrose → cyeh
Severity: enhancement → normal
Target Milestone: M15 → M14

Comment 4

19 years ago
mass reassign to leaf
Assignee: cyeh → leaf
Target Milestone: M14 → ---

Comment 5

19 years ago
This is also true for the EXE files. Currently only one: mozilla.exe
Summary: add Version tab on win32 DLLs when viewing Properties → add Version tab on win32 DLLs/EXEs when viewing Properties

Comment 6

19 years ago
The only file that seems to contain this version info is the NPNUL32.DLL in the 
plugins directory.
How is this file build?
It'd be great if there *were* some versioning system, to begin with. But there
isn't... brendan, how would i go about arbitrarily versioning dlls and exes? Use
some cvs version string (ha!)?

Comment 9

19 years ago
you need to add an .rc file for each dll and exe, and then have a script go and 
whack in the right version into each .rc file, then build that .rc file and link 
it with the dll or exe.
It's not the technique, it's the ``getting the version number to slap in'' that
i'm worried about.

Comment 11

19 years ago
slapity slapity slapity. the other thing to realize is that the Win32 version 
numbers are even more stupid and restrictive than Macintosh ones, so I dimly 
remember that there are only three dot groups and the highest number value was 

ssu knows.
There are two file versions in the VS_VERSION_INFO block. There is a 
"FileVersion" string which is completely arbitrary and I think is the one that 
shows in the file property version tab. Then there is a numeric FILEVERSION 
which consists of four comma-separated 16-bit numbers. (There are also similar 
ProductVersion and PRODUCTVERSION slots.)

That doesn't answer Leaf's question of what the versions should be, however. 
Should the Mozilla version of files be 5.0 something and Commercial be 6.0 
something? That'd be impractical since it would require a rebuild of everything 
and in the current scheme the Commercial build reuses as much of the Mozilla 
build as possible. "5.0" it is then. So what's the "something"?

Here's some stuff to bounce around:
  string: "5.0.2000091108" (with or without hours)
  string: "" (third digit is milestone)

Note that in the string form we can do stuff like "5.001" and make sense, but 
in the numeric version 5,1 and 5,001 are exactly the same so you may want to 
push the minor numbers off to the third "release" slot. But then you have less 
to play with on the date part given the 16-bit limitation.
Shouldn't this really be an XP bug?  Even though other platforms might have
different mechanisms, this is generally useful functionality.
If the version number should match the user-agent, then 5.0 it is.  If it's some 
"Mozilla version number", then we are somewhere south of 0.9 right now.

dmose: if you want this on the other platforms I'd write separate bugs. The 
fixes would be quite different and platform specific, and possibly handled by 
different folks. Let's keep this bug windows-only.

brendan: so who has the authority and interest to decide what the version 
should be? That's in large part what leaf is waiting on.
Mitchell already decreed that Mozilla will brand a 1.0 at some point, not likely
when Netscape 6 ships.  So the only reason to use 5.0 is if you have to match UA
for some reason.

Using 1.0 right now is premature.  More in a bit on a better Mozilla-branded


Comment 17

18 years ago
setting for 0.9.2 thinking mozilla wants this in for mozilla 1.0.
Target Milestone: --- → mozilla0.9.2

Comment 18

18 years ago
tired of pushing this out every milestone -> Future
Target Milestone: mozilla0.9.2 → Future

Comment 19

18 years ago
if this is not fixed, our products will look unpolished because when other 
apps/installers attempt to verify mozilla's/netscape 6's version, it will fail.

Either that or show up as x.x.x.x (for both mozilla and netscape) as I've seen 
it in one native windows installer attempting to show me what browser versions 
are installed on my system.

It might also create problems if such 3rd party native apps/installers are 
specifically looking for a particular version that they only support.  Since our 
files aren't versioned, that would be complicated.

Also, if/when xpinstall is fixed to actually properly do native version compare 
for the files being installed, this could be a blocking bug.

Comment 20

18 years ago
*** Bug 86203 has been marked as a duplicate of this bug. ***
This is really really really really simple. It should be done already. All you
have to do is add an .rc to each of the component dirs and put it in that have a version resource in it. You can make a version resource
in msvc6.0. Possibly, you can put the version resource in only one directory and
still include it in all the's.

Attached is a resource with a version in it. Just text-edit the parameters you
want and link it in. That's all. 
You can assign to me if you want.
IMHO add this .rc in one directory, have it build and link into every .dll, and
have it only link in if its a RELEASE candidate. Then you only have to edit the
.rc file once per release. Also could write a perl script to change the ver
number to the build number in the non-release. Please don't assign it to me. I
have changed my mind :-) This is really for someone with write access.
Actually, you could write a perl script to make the .rc file every time so it
would require no manual editing.
Mark H. said it could even be linked in the rules.mak file.

Comment 27

18 years ago
isn't this one a demand from Netscape to Netscape 6.1 ? If Netscape already does 
this for 6.1 cant Mozilla get it too?


18 years ago
QA Contact: cpratt → gerardok
This can be done in a perl script to generate an RC file based on the current
build number. As long as the script runs before the RC file is linked in (it
would be included in the file for that dir.), then everything
should be fine.

Wouldn't this be nice to have for 1.0?

Comment 29

18 years ago
key phrase "nice to have".

As always, we are accepting patches.
Its pretty hard for someone to make a patch when they don't even know what wants on the patch. This is commone in a lot of bugs. If you don't
ask, you don't get.
This is not something someone can write a patch for unless they know what the
template is for the version information and how it can be grabbed by a perl
file. What a developer would need is:

1) What you want to have written on the version tab of each .dll and the installer
2) Information on where the version number is generated and/or stored in Mozilla
What should be written in the version info and how it should appear in each file
should be something decided by For instance: 

1) What to show for nightly builds
2) What to show for personal builds
3) What to show for version numbers (i.e. 0.9.7)
4) If any versioning information is used on other OSes, how we can keep it
similiar in Win32
5) Possibly some info on where to get started.

Without this general information, no one would want to get started on fixing
this bug. probably has a very specific idea of what they want to
see, yet a developer wouldn't know what it is. There are probably even legal
issues involved.

I'm going to take a stab at providing some information here for someone who
wants to implement this:

Versions are a resource placed in executables much like icons are. The windows
explorer can peek at the version resource inside an executable file (or dll).
For instance, for kernel32.dll in Windows/system32 dir - the info is: 

File version: 5.1.2600.0
Description: Windows NT BASE API Client DLL
Copyright: (C) Microsoft Corporation. All rights reserved.

Company: Microsoft Corporation
File Version: 5.1.2600.0 (xpclient.010817-1148)
Internal Name: kernel32
Language: English (United States)
Original Filename: kernel32
Product Name: Microsoft(R) Windows(R) Operating System
Product Version: 5.1.2600.0

The version info is entered into a binary by first compiling the .rc file and
linking in the resulting .res file.

The win32 build system starts at the base directory which you can browse with with client.mak
(please see

client.mak builds nspr/ then mozilla/ which builds the
individual directories.

If MOZILLA_OFFICIAL is set then a buildid is generated such as 2001120113 based
on date and time.

I have no clue how people actually set if its going to be a major release such
as 0.9.6 (maybe someone else can explain that?), but however its done: 

you could make a script in mozilla/config
that compiles the .rc based on the libraries name that is passed to it.

The parameters would be the library name.

For instance, if it was the library imgbmp.dll

You would add a line for it to run the perl file you put in the config dir with
the parameter "imgbmp.dll" and it would make a version.rc file in this directory. 

You would add RESFILE = version.res to in this directory. I *think*
that it will then compile version.rc and link in version.res


Comment 33

18 years ago
I hate it when version information doesn't include a description of the file.  I
constantly use version info to try and determine what a file is.

This could be split into two groups of information.  The common information
would be the same for all DLLs and EXEs, and include:
  Company -
  Product Name - the long brand name
  Product Version - build id or milestone
  Copyright - a standard copyright blurb mentioning and maybe the
              triple license

The file-specific information would need to be defined for each DLL and EXE and
stored in the appropriate directory for the target file (eg. somewhere under
/layout for gklayout.dll).  Right now all I can think of for this is the

One question is what to do about File Version?  I think it's fine making File
Version the same as Product Version, so for nightlies the File Version would be
(eg.) 2001121103 or some derivitive with "."s in it.
Yes, except what to do we do when its a full distribution (i.e. 0.9.4) or a
personal build?

I'm working on the preliminaries for the version info. This is the first time
I've messed around with the build system, so bare with me :-)
I created the system for adding the versions to the .dlls and .exes

What it does is this:

There is a new file: /mozilla/config/ which has a rule called $(VERSION)
It calls a perl script to make the version .rc in the current dir, then compiles
it into a .res

I included it in: /mozilla/config/rules.mak

then and both link in that .res file

Depending on how you make the perl script generate the file, you can change what
shows up.

Posted image I tested it on imgbmp.dll (obsolete) —
Here is a sample of the output .dll's version information. I didn't have to put
anything in the directory of this module.

Comment 37

18 years ago
Where does the "blahblahblah" come from?
So far, just from the PERL script. But it should be trivial to make people be
able to add a comment in the module directory.
I have it finished enough that you can put the following lines in the of each module and it will carry over to the file being built
(after a lot of banging my head):

MODULE_COMMENT = comment goes here
MODULE_DESCRIPTION = description goes here

they are placed in environ variables by included in rules.mak, along
with the modules's name (such as nsBitmapDecoder) and the filename (such as

I am currently compiling the entire source tree with the one-line change to
rules.mak, the new, and the small change to If that works,
I will try testing this on the .exe files that are built to by editing

I talked to Daa on irc and heard that people are trying to get gmake to work for
a Win32 build system. I don't know what affect that will have on the versioning.
Does gmake use the same .RC files in windows? If it does, then by assigning the
same environ variables as is assigned in, there should be no change
that has to be done to (I think)
I just looked at bug 58981. Looking at that bug, I think it would be a bad idea
to add the comments and descriptions in the makefiles themselves. We probably
won't be using these makefiles in a while, and it would waste our time to put
the comments and stuff in there.

Therefore, I am going to make it use a module.ver file that contains both
comment and description.


# Mozilla License


Do you think this could be expanded to contain all the versioning information
for every OS that changes by module?

Comment 41

18 years ago
Can you make the file a header file (eg. version.h) and include it when
compiling the resource?  I know that .rc files can have #includes.

"Do you think this could be expanded to contain all the versioning information
for every OS that changes by module?"

I'm not quite sure what you mean here.  All that's in the file right now is
generic descriptions about the file.
What I mean is that could module.ver contain all the module-specific versioning
information for every operating system? I don't know how versioning works on
other oses, but it would be nice having all the versioning information for every
os in one centralized location for each module.

Like, say Mac OS had a field X that had to be different for each module and
didn't exist on every OSes version fields for binaries, then 

MAC_MODULE_X= could be added to the modules.ver file. 

Let's assume that every OS had a comment and description field in their
per-binary version information, then MODULE_COMMENT and MODULE_DESCRIPTION could
be grabbed by the version information generators of every operating system.
The big problem with version.h is it would require every module to have this
file or you would get RC compile errors. With module.ver, the perl script could
put null strings in the RC file if either:

A) the file didn't exist
B) the specific field didn't exist within the file

I think this is a much safer option.
To clarify what I meant about module.ver:

Every module probably has specific information such as comments, etc that can be
added. Some of these are generic and can probably be used by the versioning
systems of multiple operating systems. We can probably move all the
module-specific versioning information from every OS to this one file and make
it so the build system grabs it from there. That way, people would have one
place where they have to add the version info for every modules. I am not sure
what the versioning systems are for every OS, but it would be nice to have it
this way.

Another reason for using module.ver is because nmake is not going to be used
much longer and putting lines in nmake would be an extreme waste of time.

Problems: The build system doesn't know what milestone its making. Therefore, a
milestone will appear the same as a nightly build in the version info until that
is fixed. Fortunately, you can set an environment variable to let the version
info know. 

I hope in the future, that the build systems will be smart to know if its
building a milestone. I heard you have to manually go in and edit files. Don't
you consider that a waste of time? Couldn't you set an extra environ variable
along with MOZ_OFFICIAL such as MOZ_MILESTONE to let it know what milestone its
building? That incendentally, is what I used to let the version script know its
building a milestone.

Another issue is that we will have to transfer this from nmake to gmake. I don't
find that will be much of a problem. Most of the version resource creation
occurs in perl using environment variables passed in.

Also, we will need to add the module.ver files to every directory. I made it so
the build doesn't die if the module.ver file doesn't exist. It should probably
be that way until its added to all the existing directories. After that, it
would probably be a good idea to have it die so people know to make that file
when adding a new module.
I'm transferring what I have so far for my versioning script over to gmake. Take
a look at bug 80613 - Its about versioning too.

Comment 46

18 years ago
so what's the current status on your work, Brian?  Are there module.ver files,
scripts or comments checked into any makefiles?  Versioning is getting more
attention these days and I'm very interested in seeing what you've put together
so far.
Keywords: nsbeta1+
Target Milestone: Future → mozilla1.0


18 years ago
Keywords: nsbeta1+topembed+
I had stopped working on this bug for a while, thanks for reminding me. I'll
attach what I have so far soon. Let me just get it working reasonably in gmake.
why take off the nsbeta1+? There's no obvious reason a bug can't be important to
both nsbeta and topembed efforts.
Keywords: nsbeta1+
Posted file Here is the .pl file. (obsolete) —
I haven't inserted this file into my gmake build yet. I changed a couple things
just now - basically making it so that the parameters are passed on the command
line. I don't know if the gmake build has the equivalent of DEPTH - I will have
to take a look. I use it to get the build_number from a file in the config dir.
Is there a better way?
This I named

I just changed !$quiet to $quiet ne "1" btw

Comment 51

18 years ago
cool.  thanks, brian.

reassigning to asasaki since he'll be doing the Netscape side of this rather
than leaf.

Comment 52

18 years ago
actually remembering to do the reassign this time.
Assignee: leaf → asasaki

Comment 53

18 years ago
Got it to work.

Any existing RESFILE definition in's will override the auto-built
RESFILE (by design).  There are currently a number of's which do
this, so those files (including mozilla.exe) will not have an auto-built
RESFILE.  We can change this in if necessary, or just update the's.

Also, no actual milestone is passed to the script... all the versions are set
at  However, now that the patch is written it should be a simple
matter of passing a variable to the script.

The change I made to is (!$quiet) -> (!$quiet || $quiet ne "1")
since the ($quiet ne "1") gives warnings if you don't pass the -QUIET
parameter.  I tried to obsolete the previous attachments but don't have the
privs to do so.

Comment 54

18 years ago
ok, I can't edit my own attachment to make it application/zip rather than
application/octet-stream... =P reattach?

- newbie patcher


18 years ago
Attachment #72502 - Attachment mime type: application/octet-stream → application/zip
Patches should be attached as patches -- i.e. plain text with the "patch" box 
Does this work with the gmake windows builds also?

Comment 57

18 years ago
a cvs diff -u will show changes to existing files, but doesn't pick up new
files... hence the zip file.

the patch only works for the nmake build (since i haven't gotten a gmake build
working yet) but it shouldn't be terribly hard to port it over.

Comment 58

18 years ago
in the future, please attach diffs and archives of new files separately.

fwiw if you have cvs commit privs, you can do |cvs add file| and |cvs diff -N| 
to diff it. if you don't have cvs commit privs, you can try fiddling with cvsdo 
from but don't worry about that as new binary 
files should still be in zips so we'll presumably always accept new files 
(including text/source) in them.

Comment 59

18 years ago
Posted file updated (new file) (obsolete) —
Changed RESFILE_STRING to RC_STRING to keep same terminology between nmake and
gmake builds.  Also -MODNAME $(MODULE) isn't default anymore... some dlls/exes
don't define $(MODULE) and you end up with a module name of "-DEPTH".

Comment 60

18 years ago
This patch, along with the new version of does the same thing
for the gmake build... builds a .rc file (and by rule, a .res file) to link to
.dll and .exe files if there isn't a RESFILE already defined.

Just built, adds the version and a little bit of description.

Comment 61

18 years ago
Comment on attachment 72906 [details]
updated (new file)

># The contents of this file are subject to the Netscape Public
># License Version 1.1 (the "License"); you may not use this file
># except in compliance with the License. You may obtain a copy of
># the License at
># Software distributed under the License is distributed on an "AS
># IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
># implied. See the License for the specific language governing
># rights and limitations under the License.
># The Original Code is code.
># The Initial Developer of the Original Code is Netscape
># Communications Corporation.  Portions created by Netscape are
># Copyright (C) 1998 Netscape Communications Corporation. All
># Rights Reserved.
># Contributor(s): 
>!if !defined(RESFILE) && (defined(DLL) || defined(PROGRAM)) && !defined(CONFIG_RESFILE_INC)
>#// Build .rc and .res files if $(RESFILE) isn't defined.
>#// PBI      : ??
>#// DEBUG    : $(MOZ_DEBUG)
>#// MSTONE   : ??
>#// OBJDIR   : $(OBJDIR)
>#// DEPTH    : $(DEPTH)
>#// BINARY   : $(DLL)
>#// BITS     : $(MOZ_BITS)
>#// RCINCLUDE: ??
>#// QUIET    : optional
>!if defined(MOZ_DEBUG)
>!if defined(MOZILLA_OFFICAL)
>!if defined(MODULE)
>    $(PERL) $(DEPTH)\config\ $(RC_STRING)
>    rc $(OBJDIR)\module.rc

Comment 62

18 years ago
*sigh*, i'm gonna go hide my head in shame.
installing/admining bugzilla != using it.

anyway, that was me trying to fix attachment #72906 [details] since I had added the ifdef
lines but forgot to take the -MODNAME $(MODULE) out of the default string.

Comment 63

18 years ago
Comment on attachment 72906 [details]
updated (new file)

This file doesn't have the tri-license.

Comment 64

18 years ago
yeah that's some strange bug in either mozilla or bugzilla, don't worry many 
many developers trip on it. i'm going to try to trip on it in my corporate 
install ...

Comment 65

18 years ago
hm, another note,
it doesn't create RESFILE for $(SIMPLE_PROGRAMS) or whatever, only for
$(PROGRAM) files.  not sure if this is a bug, or by design.

Comment 67

17 years ago
Ok, now if MOZILLA_OFFICIAL or BUILD_OFFICIAL is set and config/milestone.txt
(which should actually read "0.9.9+" for the current trunk) only has a x.x.x
milestone, then dlls and programs are automagically given the version in the
milestone.txt (in this case, 0.9.9) in both nmake and gmake.

Also added clobber/clobber_resfile clean/clean_resfile targets for nmake and
gmake, respectively.

I will eventually use config/milestone.txt and to update *all*
hardcoded references to milestones, via a list of files and
s/__MOZ_MAJOR_REVISION__/$MOZ_MAJOR_REVISION/g or whatever, from a template to a
cpp or header or whatever file.  But for now we have versioning working to a
workable level with this patch...

Looking for r= and sr=... TIA
Comment on attachment 74259 [details] [diff] [review]
updated gmake and nmake patch (including new files)

In config/, setting RESFILE=$(srcdir)/modules.res will cause the .res
file to be generated in the srcdir.  That will break our objdir builds. (In
general, the RESFILE variable is backwards from the usual gmake convention of
using the srcfiles not the output file to designate what gets built.)  I think
that you want to target $(RESFILE) instead RESFILE.  And actually, that RESFILE
rule shouldn't be needed as we already have a rule in config/ that
should generate %.res from %.rc if RESFILE is set.  Wrt module.rc rule, we do
not want to create that file in the srcdir so $(srcdir) shouldn't be used in
that ruleset and OBJDIR shouldn't be set to $(srcdir).
Attachment #74259 - Flags: needs-work+
Oh, and you'll want to call the perl script in config/ using $(PERL).
 If RC_STRING isn't going to be used outside of, can you prefix it
with an _ to avoid potential namespace issues.


Comment 70

17 years ago
Posted patch updated patch (obsolete) — Splinter Review
Changes made, tested.  This isn't a full patch, just the updated  I
can attach another full patch if necessary.
Comment on attachment 74443 [details] [diff] [review] updated patch

aki is the man. r=leaf
Attachment #74443 - Flags: review+
Comment on attachment 74443 [details] [diff] [review] updated patch

oops! i take that back. It needs the MPL license header.
Attachment #74443 - Flags: review+ → needs-work+
The OBJDIR ifdef is unneeded.  We don't support the .OBJ subdirs in the gmake
build.  Other than that, it looks good. r=cls

Comment 74

17 years ago
I don't set OBJDIR so if I don't have that in there it defaults to /module.rc
which puts it in d:/ ...

Should I add the MPL to all new files, other than the milestone.txt?
So don't use $(OBJDIR) at all.  Just remove the first part of the ifdef that
uses $(OBJDIR) and just use ./ instead.  Yes, we should be using the MPL-based
triple license.  Sorry, I missed that before.

Comment 76

17 years ago
Ok, added MPL and removed the OBJDIR ifdef from full patch.
Comment on attachment 74453 [details] [diff] [review]
new full patch (everything above this is obsolete)

Sorry, one last thing. needs to know about the srcdir. 
Otherwise, it's going to expect to find module.ver in the current dir which
will break in objdir builds.
Attachment #74453 - Flags: needs-work+

Comment 78

17 years ago
hm, do you mean -OBJDIR? that's in the first line now in


*However* I should probably s/RC_STRING/_RC_STRING/ in as well. 
Anything else before I make a new patch?

Comment 79

17 years ago
oh, I see.  nevermind, updating to send -SRCDIR...
Comment on attachment 74463 [details] [diff] [review]
new full patch incorporating new -SRCDIR option and _RC_STRING in

Attachment #74463 - Flags: review+

Comment 82

17 years ago
Since $DEPTH in the .pl files is called from and via
-DEPTH, changing -DEPTH $(DEPTH) to -DEPTH $(topsrcdir) in and to fix objdir builds.
Comment on attachment 75088 [details] [diff] [review]
call perl scripts with -DEPTH $(topsrcdir)

In config/, 
+	$(PERL) $(DEPTH)/config/ $(_RC_STRING)
should be
+	$(PERL) $(topsrcdir)/config/ $(_RC_STRING)
. needs to know about both $DEPTH & $topsrcdir as separate
variables.  When $DEPTH is used for --depth, tries to call from the objtree.	When $topsrcdir is used for DEPTH, tries to read the build_number from the srctree.
Attachment #75088 - Flags: needs-work+
Comment on attachment 75281 [details] [diff] [review]
fixed topsrcdir/depth issues and built objdir build

Attachment #75281 - Flags: review+

>Any existing RESFILE definition in's will override the auto-built
>RESFILE (by design).  There are currently a number of's which do
>this, so those files (including mozilla.exe) will not have an auto-built
>RESFILE.  We can change this in if necessary, or just update the

I had made it so that if there was a RESFILE definition, you can pass this
into as --RCINCLUDE. The values will be merged in when necessary
to the new module.rc. You might not decide to use this feature for, but I wanted to let you know it was there.

+#// PBI      : ??
+#// DEBUG    : $(MOZ_DEBUG)
+#// MSTONE   : grabs automagically
+#// OBJDIR   : $(OBJDIR)
+#// DEPTH    : $(DEPTH)
+#// BINARY   : ??
+#// BITS     : $(MOZ_BITS)
+#// RCINCLUDE: ??
+#// QUIET    : 1

PBI is private build info, which is a personal information string for developers
to keep track of their builds and could be passed in through an environment var
at the start of build (but isn't really necessary). IE: "Private build for
testing the new mouse cursor"
BINARY is the binary name of the file being created (mozilla.exe)


RCINCLUDE is what I just mentioned above.

BTW - Excellent job.

Comment on attachment 75281 [details] [diff] [review]
fixed topsrcdir/depth issues and built objdir build

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #75281 - Flags: approval+


17 years ago
Attachment #38737 - Attachment is obsolete: true


17 years ago
Attachment #61498 - Attachment is obsolete: true


17 years ago
Attachment #70580 - Attachment is obsolete: true


17 years ago
Attachment #72502 - Attachment is obsolete: true


17 years ago
Attachment #72906 - Attachment is obsolete: true


17 years ago
Attachment #72907 - Attachment is obsolete: true


17 years ago
Attachment #74259 - Attachment is obsolete: true


17 years ago
Attachment #74443 - Attachment is obsolete: true


17 years ago
Attachment #74453 - Attachment is obsolete: true


17 years ago
Attachment #74463 - Attachment is obsolete: true


17 years ago
Attachment #75088 - Attachment is obsolete: true
checked in on behalf of aki; if dependencies catch this, the 8am builds today
should show the change.
Comment on attachment 75281 [details] [diff] [review]
fixed topsrcdir/depth issues and built objdir build

>+# The Initial Developer of the Original Code is Aki Sasaki <>

As a Netscape employee creating stuff as part of your job you should
have put Netscape Communications Corporation here instead of your own
name (until they tell us to switch to AOLTW instead). Your name can go
under Contributors if you want. Some folks add a comment after their name
saying they're the original author. Nice for professional credit, but
meaningless for copyright in a "work for hire".

>+# Portions created by the Initial Developer are Copyright (C) 2001

Should be 2002, right?

Ditto on the other files you added

>+#// Build .rc and .res files if $(RESFILE) isn't defined.
>+#// PBI      : ??
>+#// DEBUG    : $(MOZ_DEBUG)
>+#// MSTONE   : grabs automagically
>+#// OBJDIR   : $(OBJDIR)
>+#// MODNAME  : $(MODULE)
>+#// DEPTH    : $(DEPTH)
>+#// BINARY   : ??
>+#// BITS     : $(MOZ_BITS)
>+#// RCINCLUDE: ??
>+#// QUIET    : 1

Please fill in the question marks with the info Brian provided

>+# PBI      : ??
>+# BINARY   : ??

ditto here


You could have used GARBAGE in the nmake files, too, instead of
an explicit clobber:: rule

>+	-rm -f $(RESFILE) $(RCFILE)
>+clean:: clean_resfile

If you have these defined as GARBAGE, you don't need this too,
do you? Or is the GARBAGE mechanism broken these days?

>+# PBI - your private build information (if not a milestone or nightly)
>+# BINARY - Holds the name of the binary file
>+# RCINCLUDE - Holds the name of the RC File to include or ""

Here's the info to fill in the ??? above

Shouldn't have checked in w/out sr=, approval doesn't override that.
Please clean up the above minor nits and re-check in. sr=dveditz
Attachment #75281 - Flags: superreview+

Comment 90

17 years ago

The reason behind the ??? is because these currently have no way of getting
automatically passed... I realized what their function was, but didn't know the
best way to put those in, and didn't think they were necessary for immediate
checkin.  So I can update the comments, but PBI, BINARY, and RCINCLUDE aren't
getting passed to the script under the current patch.

Apologies for not getting sr=, I misinterpreted which says that gmake related
stuff can just go in without sr= if it has r=cls.  However, there is an nmake
side to this, so I should have gotten sr=.

Fixing the patch.
My bad, didn't realize build stuff had an exemption from super-review. You're
always welcome to seek extra reviews, though. An extra pair of eyes can only help.

Comment 92

17 years ago
This should be disabled for cvs builds, the versioning needs to be put inside 
an ifdef MOZILLA_OFFICIAL. There's no point to having 'File Version:' 
in cvs builds.

Comment 93

17 years ago
no, it doesn't.  cvs builds need version numbers so that we can tell them apart
from official release builds.  eventually that will be replaced by
something more useful that has version information but clearly indicates that
the build is a developer build.

Comment 94

17 years ago
Can you remove the 'use diagnostics;' pragma from That 
should not, in general, be in production code. (It broke a couple of people's 
builds as well, although that was due to a misconfigured perl installation
on their part).

Comment 95

17 years ago
Er, ignore that last comment. leaf's most recent checkin comment says that he 
removed the 'use diagnostics;'.

Comment 96

17 years ago
ADT1 - required for MRE
Whiteboard: [adt1]

Comment 97

17 years ago
this should be pretty much done, other than leaf's build_number patch.  after
that goes in i'll mark this resolved and any new issues can go in a new bug,
unless someone has an objection to that.

Comment 98

17 years ago
resolving.  any new issues to a new bug.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 99

17 years ago

Comment 100

17 years ago
I see the Version tab for DLLs but not for Mozilla.exe.  Should I?
Yes, mozilla.exe should also get a version tab. It's perhaps the most important
one from a user's perspective.
Resolution: FIXED → ---

Comment 102

17 years ago
damn, I just checked the Netscape files.  this is probably due to a hard coded
.rc for the mozilla.exe file.  this should probably be a separate bug since
versioning mozilla.exe is not adt1, nsbeta1+ or topembed+

Aki - take a look at this when you have a chance but release work comes first
since the dlls are versioned and that's the most important thing.

Comment 103

17 years ago
additional problems:
- missing versioninfo on mozilla-win32-installer.exe
- fileversion on files (fx ISimpleDOMDocumentMarshal.dll) are
- description is empty
- Company name should be "" not "Mozilla"
- Legal trademark should perhaps mention MPL, etc
- Original filename is empty


17 years ago
Keywords: nsbeta1+, topembed+
Whiteboard: [adt1]
Replacing silently removed keywords, if this regresses we'll want these
important markers.
Keywords: nsbeta1+, topembed+
Whiteboard: [adt1]

Comment 105

17 years ago
fine.  resolved/fixed/verified.  the new bug is to cover adding version
information to the mozilla.exe file.
Last Resolved: 17 years ago17 years ago
Keywords: nsbeta1+, topembed+
Resolution: --- → FIXED
Whiteboard: [adt1]

Comment 106

17 years ago
I've filed:
bug 136684 "missing versioninfo on mozilla-win32-installer.exe "
bug 136686 "most of versioninfo is bugus or missing"
restoring keywords for completion/tracking queries. Again.
Keywords: nsbeta1+, topembed+
Whiteboard: [adt1]

Comment 108

17 years ago
my bad, I must have removed them by mistake when resolving the bug the second time.
re: mozilla.exe - That is why I added the ability to merge the .rc files. All
you have to do is pass in the name of the rc file for binaries for which it is
already in existance, and have it merge them.
Looks like the mozilla.exe issue was fixed in bug 136673
Blocks: 80613
*** Bug 50627 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.