Closed
Bug 23560
Opened 25 years ago
Closed 23 years ago
add Version tab on win32 DLLs/EXEs when viewing Properties
Categories
(SeaMonkey :: Build Config, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0
People
(Reporter: bugzilla, Assigned: asasaki)
References
Details
(Keywords: topembed+, Whiteboard: [adt1])
Attachments
(1 file, 11 obsolete files)
(deleted),
patch
|
netscape
:
review+
dveditz
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
It should be possible to right-click on all installed DLL, EXE files in the
Mozilla directory and select Properties -> Version.
Updated•25 years ago
|
Severity: normal → enhancement
Status: NEW → ASSIGNED
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
Comment 2•25 years ago
|
||
cc'ing cyeh since we talked about this bug last week.
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
beta2.
ccing ssu, leaf@mozilla.org.
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
Status: ASSIGNED → NEW
Target Milestone: M15 → M14
mass reassign to leaf
Assignee: cyeh → leaf
Target Milestone: M14 → ---
Reporter | ||
Comment 5•25 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
Reporter | ||
Comment 6•24 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?
Reporter | ||
Comment 7•24 years ago
|
||
How to add version info:
http://lxr.mozilla.org/mozilla/source/modules/plugin/default/windows/npnul32.rc#
76
Comment 8•24 years ago
|
||
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!)?
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.
Comment 10•24 years ago
|
||
It's not the technique, it's the ``getting the version number to slap in'' that
i'm worried about.
Status: NEW → ASSIGNED
Comment 11•24 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
32.
ssu knows.
Comment 12•24 years ago
|
||
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: "5.0.18.20000911" (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.
Comment 13•24 years ago
|
||
Shouldn't this really be an XP bug? Even though other platforms might have
different mechanisms, this is generally useful functionality.
Comment 14•24 years ago
|
||
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.
/be
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
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
number.
/be
Comment 17•24 years ago
|
||
setting for 0.9.2 thinking mozilla wants this in for mozilla 1.0.
Target Milestone: --- → mozilla0.9.2
Comment 18•23 years ago
|
||
tired of pushing this out every milestone -> Future
Target Milestone: mozilla0.9.2 → Future
Comment 19•23 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.
Reporter | ||
Comment 20•23 years ago
|
||
*** Bug 86203 has been marked as a duplicate of this bug. ***
Comment 21•23 years ago
|
||
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
makefile.win 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 makefile.win's.
Attached is a resource with a version in it. Just text-edit the parameters you
want and link it in. That's all.
Comment 22•23 years ago
|
||
You can assign to me if you want.
Comment 23•23 years ago
|
||
Comment 24•23 years ago
|
||
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.
Comment 25•23 years ago
|
||
Actually, you could write a perl script to make the .rc file every time so it
would require no manual editing.
Comment 26•23 years ago
|
||
Mark H. said it could even be linked in the rules.mak file.
Reporter | ||
Comment 27•23 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?
Comment 28•23 years ago
|
||
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 makefile.win file for that dir.), then everything
should be fine.
Wouldn't this be nice to have for 1.0?
Comment 29•23 years ago
|
||
key phrase "nice to have".
As always, we are accepting patches.
Comment 30•23 years ago
|
||
Its pretty hard for someone to make a patch when they don't even know what
mozilla.org wants on the patch. This is commone in a lot of bugs. If you don't
ask, you don't get.
Comment 31•23 years ago
|
||
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
Comment 32•23 years ago
|
||
What should be written in the version info and how it should appear in each file
should be something decided by mozilla.org. 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. Mozilla.org 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.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/rc_7x2d.asp
The win32 build system starts at the base directory which you can browse with
http://lxr.mozilla.org/seamonkey/source/ with client.mak
(please see http://www.mozilla.org/build/win32.html)
client.mak builds nspr/gmakefile.win then mozilla/makefile.win which builds the
individual directories.
http://lxr.mozilla.org/seamonkey/source/makefile.win
If MOZILLA_OFFICIAL is set then a buildid is generated such as 2001120113 based
on date and time.
http://www.mozilla.org/build/distribution.html
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
http://lxr.mozilla.org/seamonkey/source/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
http://lxr.mozilla.org/seamonkey/source/modules/libpr0n/decoders/bmp/Makefile.win
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 Makefile.win in this directory. I *think*
that it will then compile version.rc and link in version.res
Comment 33•23 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 - mozilla.org
Product Name - the long brand name
Product Version - build id or milestone
Copyright - a standard copyright blurb mentioning mozilla.org 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
Description.
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.
Comment 34•23 years ago
|
||
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 :-)
Comment 35•23 years ago
|
||
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/version.inc 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 exe.inc and dll.inc both link in that .res file
Depending on how you make the perl script generate the file, you can change what
shows up.
Comment 36•23 years ago
|
||
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•23 years ago
|
||
Where does the "blahblahblah" come from?
Comment 38•23 years ago
|
||
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.
Comment 39•23 years ago
|
||
I have it finished enough that you can put the following lines in the
Makefile.win 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 version.inc included in rules.mak, along
with the modules's name (such as nsBitmapDecoder) and the filename (such as
bmplib.dll)
I am currently compiling the entire source tree with the one-line change to
rules.mak, the new version.inc, and the small change to dll.inc. If that works,
I will try testing this on the .exe files that are built to by editing exe.inc.
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 version.inc, there should be no change
that has to be done to version.pl (I think)
Comment 40•23 years ago
|
||
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.
ie:
# Mozilla License
MODULE_COMMENT=comment
MODULE_DESCRIPTION=description
Do you think this could be expanded to contain all the versioning information
for every OS that changes by module?
Comment 41•23 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.
Comment 42•23 years ago
|
||
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.
Comment 43•23 years ago
|
||
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
or
B) the specific field didn't exist within the file
I think this is a much safer option.
Comment 44•23 years ago
|
||
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.
Comment 45•23 years ago
|
||
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•23 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
Updated•23 years ago
|
Comment 47•23 years ago
|
||
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.
Comment 48•23 years ago
|
||
why take off the nsbeta1+? There's no obvious reason a bug can't be important to
both nsbeta and topembed efforts.
Keywords: nsbeta1+
Comment 49•23 years ago
|
||
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?
Comment 50•23 years ago
|
||
This I named version_win.pl
I just changed !$quiet to $quiet ne "1" btw
Comment 51•23 years ago
|
||
cool. thanks, brian.
reassigning to asasaki since he'll be doing the Netscape side of this rather
than leaf.
Comment 52•23 years ago
|
||
actually remembering to do the reassign this time.
Assignee: leaf → asasaki
Status: ASSIGNED → NEW
Assignee | ||
Comment 53•23 years ago
|
||
Got it to work.
Any existing RESFILE definition in makefile.win's will override the auto-built
RESFILE (by design). There are currently a number of makefile.win's which do
this, so those files (including mozilla.exe) will not have an auto-built
RESFILE. We can change this in resfile.inc if necessary, or just update the
makefile.win's.
Also, no actual milestone is passed to the script... all the versions are set
at 0.0.0.0. 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 version_win.pl 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.
Assignee | ||
Comment 54•23 years ago
|
||
ok, I can't edit my own attachment to make it application/zip rather than
application/octet-stream... =P reattach?
- newbie patcher
Attachment #72502 -
Attachment mime type: application/octet-stream → application/zip
Comment 55•23 years ago
|
||
Patches should be attached as patches -- i.e. plain text with the "patch" box
checked.
Comment 56•23 years ago
|
||
Does this work with the gmake windows builds also?
Assignee | ||
Comment 57•23 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.
Status: NEW → ASSIGNED
Comment 58•23 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 http://www.red-bean.com/cvsutils/ 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.
Assignee | ||
Comment 59•23 years ago
|
||
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".
Assignee | ||
Comment 60•23 years ago
|
||
This patch, along with the new version of version_win.pl 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 0.0.0.0 version and a little bit of description.
Assignee | ||
Comment 61•23 years ago
|
||
Comment on attachment 72906 [details]
updated resfile.inc (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 http://www.mozilla.org/NPL/
>#
># 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 mozilla.org 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)
>CONFIG_RESFILE_INC=1
>
>#//------------------------------------------------------------------------
>#// Build .rc and .res files if $(RESFILE) isn't defined.
>#// PBI : ??
>#// DEBUG : $(MOZ_DEBUG)
>#// OFFICIAL : $(MOZILLA_OFFICIAL)
>#// MSTONE : ??
>#// OBJDIR : $(OBJDIR)
>#// MODNAME : $(MODULE)
>#// DEPTH : $(DEPTH)
>#// BINARY : $(DLL)
>#// BITS : $(MOZ_BITS)
>#// RCINCLUDE: ??
>#// QUIET : optional
>#//------------------------------------------------------------------------
>
>RC_STRING = -OBJDIR $(OBJDIR) -DEPTH $(DEPTH) -BINARY $(DLL) -BITS $(MOZ_BITS) -QUIET 1
>!if defined(MOZ_DEBUG)
>RC_STRING = $(RC_STRING) -DEBUG 1
>!endif
>!if defined(MOZILLA_OFFICAL)
>RC_STRING = $(RC_STRING) -OFFICIAL 1
>!endif
>!if defined(MODULE)
>RC_STRING = $(RC_STRING) -MODNAME $(MODULE)
>!endif
>
>RESFILE=$(OBJDIR)\module.res
>
>$(RESFILE):
> $(PERL) $(DEPTH)\config\version_win.pl $(RC_STRING)
> rc $(OBJDIR)\module.rc
>
>!endif # !RESFILE && (DLL||PROGRAM) && !CONFIG_RESFILE_INC
Assignee | ||
Comment 62•23 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•23 years ago
|
||
Comment on attachment 72906 [details]
updated resfile.inc (new file)
This file doesn't have the tri-license.
Comment 64•23 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 ...
Assignee | ||
Comment 65•23 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.
Assignee | ||
Comment 66•23 years ago
|
||
Assignee | ||
Comment 67•23 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 milestone.pl 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 68•23 years ago
|
||
Comment on attachment 74259 [details] [diff] [review]
updated gmake and nmake patch (including new files)
In config/version.mk, 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/rules.mk 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+
Comment 69•23 years ago
|
||
Oh, and you'll want to call the perl script in config/version.mk using $(PERL).
If RC_STRING isn't going to be used outside of version.mk, can you prefix it
with an _ to avoid potential namespace issues.
Assignee | ||
Comment 70•23 years ago
|
||
Changes made, tested. This isn't a full patch, just the updated version.mk. I
can attach another full patch if necessary.
Comment 71•23 years ago
|
||
Comment on attachment 74443 [details] [diff] [review]
version.mk updated patch
aki is the man. r=leaf
Attachment #74443 -
Flags: review+
Comment 72•23 years ago
|
||
Comment on attachment 74443 [details] [diff] [review]
version.mk updated patch
oops! i take that back. It needs the MPL license header.
Attachment #74443 -
Flags: review+ → needs-work+
Comment 73•23 years ago
|
||
The OBJDIR ifdef is unneeded. We don't support the .OBJ subdirs in the gmake
build. Other than that, it looks good. r=cls
Assignee | ||
Comment 74•23 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?
Comment 75•23 years ago
|
||
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.
Assignee | ||
Comment 76•23 years ago
|
||
Ok, added MPL and removed the OBJDIR ifdef from version.pl... full patch.
Comment 77•23 years ago
|
||
Comment on attachment 74453 [details] [diff] [review]
new full patch (everything above this is obsolete)
Sorry, one last thing. Version_win.pl 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+
Assignee | ||
Comment 78•23 years ago
|
||
hm, do you mean -OBJDIR? that's in the first line now in version.mk
+_RC_STRING = -QUIET 1 -DEPTH $(DEPTH) -BITS $(MOZ_BITS) -OBJDIR .
*However* I should probably s/RC_STRING/_RC_STRING/ in version.inc as well.
Anything else before I make a new patch?
Assignee | ||
Comment 79•23 years ago
|
||
oh, I see. nevermind, updating to send -SRCDIR...
Assignee | ||
Comment 80•23 years ago
|
||
*cross fingers*
Comment 81•23 years ago
|
||
Comment on attachment 74463 [details] [diff] [review]
new full patch incorporating new -SRCDIR option and _RC_STRING in version.inc
r=cls
Attachment #74463 -
Flags: review+
Assignee | ||
Comment 82•23 years ago
|
||
Since $DEPTH in the .pl files is called from version.inc and version.mk via
-DEPTH, changing -DEPTH $(DEPTH) to -DEPTH $(topsrcdir) in version.mk and
version.inc to fix objdir builds.
Comment 83•23 years ago
|
||
Comment on attachment 75088 [details] [diff] [review]
call perl scripts with -DEPTH $(topsrcdir)
In config/version.mk,
+ $(PERL) $(DEPTH)/config/version_win.pl $(_RC_STRING)
should be
+ $(PERL) $(topsrcdir)/config/version_win.pl $(_RC_STRING)
.
version_win.pl needs to know about both $DEPTH & $topsrcdir as separate
variables. When $DEPTH is used for --depth, version_win.pl tries to call
milestone.pl from the objtree. When $topsrcdir is used for DEPTH,
version_win.pl tries to read the build_number from the srctree.
Attachment #75088 -
Flags: needs-work+
Assignee | ||
Comment 84•23 years ago
|
||
Comment 85•23 years ago
|
||
Comment on attachment 75281 [details] [diff] [review]
fixed topsrcdir/depth issues and built objdir build
r=cls
Attachment #75281 -
Flags: review+
Comment 86•23 years ago
|
||
Aki:
>Any existing RESFILE definition in makefile.win's will override the auto-built
>RESFILE (by design). There are currently a number of makefile.win's which do
>this, so those files (including mozilla.exe) will not have an auto-built
>RESFILE. We can change this in resfile.inc if necessary, or just update the
>makefile.win's.
I had made it so that if there was a RESFILE definition, you can pass this
into version_win.pl as --RCINCLUDE. The values will be merged in when necessary
to the new module.rc. You might not decide to use this feature for
version_win.pl, but I wanted to let you know it was there.
+#// PBI : ??
+#// DEBUG : $(MOZ_DEBUG)
+#// OFFICIAL : $(MOZILLA_OFFICIAL)
+#// MSTONE : grabs automagically
+#// OBJDIR : $(OBJDIR)
+#// MODNAME : $(MODULE)
+#// 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)
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/rc_7x2d.asp)
RCINCLUDE is what I just mentioned above.
BTW - Excellent job.
Comment 87•23 years ago
|
||
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+
Assignee | ||
Updated•23 years ago
|
Attachment #38737 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #61498 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #70580 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #72502 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #72906 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #72907 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #74259 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #74443 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #74453 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #74463 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #75088 -
Attachment is obsolete: true
Comment 88•23 years ago
|
||
checked in on behalf of aki; if dependencies catch this, the 8am builds today
should show the change.
Comment 89•23 years ago
|
||
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 <asasaki@netscape.com>
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)
>+#// OFFICIAL : $(MOZILLA_OFFICIAL)
>+#// 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 : ??
>+# RCINCLUDE: ??
ditto here
>+GARBAGE += $(RESFILE) $(RCFILE)
You could have used GARBAGE in the nmake files, too, instead of
an explicit clobber:: rule
>+clean_resfile:
>+ -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+
Assignee | ||
Comment 90•23 years ago
|
||
ok.
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
http://www.mozilla.org/hacking/reviewers.html 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.
Comment 91•23 years ago
|
||
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•23 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: 0.0.0.0'
in cvs builds.
Comment 93•23 years ago
|
||
no, it doesn't. cvs builds need version numbers so that we can tell them apart
from official release builds. eventually that 0.0.0.0 will be replaced by
something more useful that has version information but clearly indicates that
the build is a developer build.
Comment 94•23 years ago
|
||
Can you remove the 'use diagnostics;' pragma from version_win.pl. 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•23 years ago
|
||
Er, ignore that last comment. leaf's most recent checkin comment says that he
removed the 'use diagnostics;'.
Assignee | ||
Comment 97•23 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.
Assignee | ||
Comment 98•23 years ago
|
||
resolving. any new issues to a new bug.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 100•23 years ago
|
||
I see the Version tab for DLLs but not for Mozilla.exe. Should I?
Comment 101•23 years ago
|
||
Yes, mozilla.exe should also get a version tab. It's perhaps the most important
one from a user's perspective.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 102•23 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.
Reporter | ||
Comment 103•23 years ago
|
||
additional problems:
- missing versioninfo on mozilla-win32-installer.exe
- fileversion on files (fx ISimpleDOMDocumentMarshal.dll) are 0.0.0.0
- description is empty
- Company name should be "Mozilla.org" not "Mozilla"
- Legal trademark should perhaps mention MPL, etc
- Original filename is empty
Updated•23 years ago
|
Comment 104•23 years ago
|
||
Replacing silently removed keywords, if this regresses we'll want these
important markers.
Comment 105•23 years ago
|
||
fine. resolved/fixed/verified. the new bug is
http://bugzilla.mozilla.org/show_bug.cgi?id=136673 to cover adding version
information to the mozilla.exe file.
Reporter | ||
Comment 106•23 years ago
|
||
I've filed:
bug 136684 "missing versioninfo on mozilla-win32-installer.exe "
bug 136686 "most of versioninfo is bugus or missing"
Status: RESOLVED → VERIFIED
Comment 107•23 years ago
|
||
restoring keywords for completion/tracking queries. Again.
Comment 108•23 years ago
|
||
my bad, I must have removed them by mistake when resolving the bug the second time.
Comment 109•23 years ago
|
||
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.
Comment 110•23 years ago
|
||
Looks like the mozilla.exe issue was fixed in bug 136673
Comment 111•22 years ago
|
||
*** Bug 50627 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•