It should be possible to right-click on all installed DLL, EXE files in the Mozilla directory and select Properties -> Version.
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
Changing QA Contact to self.
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, firstname.lastname@example.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 → ---
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
The only file that seems to contain this version info is the NPNUL32.DLL in the plugins directory. How is this file build?
How to add version info: http://lxr.mozilla.org/mozilla/source/modules/plugin/default/windows/npnul32.rc# 76
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.
It's not the technique, it's the ``getting the version number to slap in'' that i'm worried about.
Status: NEW → ASSIGNED
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.
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: "184.108.40.20600911" (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. /be
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 number. /be
setting for 0.9.2 thinking mozilla wants this in for mozilla 1.0.
Target Milestone: --- → mozilla0.9.2
tired of pushing this out every milestone -> Future
Target Milestone: mozilla0.9.2 → Future
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.
*** 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 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.
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.
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?
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?
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 mozilla.org 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 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
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.
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/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.
Here is a sample of the output .dll's version information. I didn't have to put anything in the directory of this module.
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 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)
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?
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 or 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.
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.
Target Milestone: Future → mozilla1.0
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.
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 version_win.pl I just changed !$quiet to $quiet ne "1" btw
cool. thanks, brian. reassigning to asasaki since he'll be doing the Netscape side of this rather than leaf.
actually remembering to do the reassign this time.
Assignee: leaf → asasaki
Status: ASSIGNED → NEW
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.
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
Patches should be attached as patches -- i.e. plain text with the "patch" box checked.
Does this work with the gmake windows builds also?
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
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.
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".
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.
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
*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 on attachment 72906 [details] updated resfile.inc (new file) This file doesn't have the tri-license.
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 ...
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.
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 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+
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.
Changes made, tested. This isn't a full patch, just the updated version.mk. I can attach another full patch if necessary.
Comment on attachment 74443 [details] [diff] [review] version.mk updated patch aki is the man. r=leaf
Attachment #74443 - Flags: review+
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+
The OBJDIR ifdef is unneeded. We don't support the .OBJ subdirs in the gmake build. Other than that, it looks good. r=cls
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.
Ok, added MPL and removed the OBJDIR ifdef from version.pl... full patch.
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+
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?
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 version.inc r=cls
Attachment #74463 - Flags: review+
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 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+
Comment on attachment 75281 [details] [diff] [review] fixed topsrcdir/depth issues and built objdir build r=cls
Attachment #75281 - Flags: review+
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 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+
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 <email@example.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+
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.
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.
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.
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.
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).
Er, ignore that last comment. leaf's most recent checkin comment says that he removed the 'use diagnostics;'.
ADT1 - required for MRE
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.
resolving. any new issues to a new bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
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
Replacing silently removed keywords, if this regresses we'll want these important markers.
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.
I've filed: bug 136684 "missing versioninfo on mozilla-win32-installer.exe " bug 136686 "most of versioninfo is bugus or missing"
Status: RESOLVED → VERIFIED
restoring keywords for completion/tracking queries. Again.
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
*** Bug 50627 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.