Last Comment Bug 650699 - Sort out MSVC DLLs packaging in Debug builds.
: Sort out MSVC DLLs packaging in Debug builds.
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: x86 Windows Server 2003
: -- normal (vote)
: mozilla6
Assigned To: Serge Gautherie (:sgautherie)
:
Mentors:
Depends on: 605701
Blocks: 652296 565774 652263 652297
  Show dependency treegraph
 
Reported: 2011-04-17 17:36 PDT by Serge Gautherie (:sgautherie)
Modified: 2011-04-22 18:50 PDT (History)
2 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix


Attachments
(Av1) In debug builds, don't warn nor package [Checked in: Comment 7] (1.61 KB, patch)
2011-04-17 19:22 PDT, Serge Gautherie (:sgautherie)
ted: review+
ted: approval‑mozilla‑aurora-
Details | Diff | Splinter Review

Description Serge Gautherie (:sgautherie) 2011-04-17 17:36:50 PDT
Current situation (see bug 565774) is:
*Debug Firefox does include the 1+3 non-debug redist files.
*Debug SeaMonkey reports that these files are unavailable to be packaged.
*(I didn't check other apps.)

***

Bug 565774 comment 7:
{
Serge Gautherie (:sgautherie)      2011-02-16 05:42:38 PST

Ben, could you tell us where the Firefox WIN32_REDIST_DIR setting comes from?
(Afaics, not from build nor mozilla-central repositories...)
}

Bug 565774 comment 8:
{
Justin Wood (:Callek)      2011-02-17 08:57:43 PST

<ted> the debug CRT is not redistributable, so we can't package it
}

1-
Packaging non-debug DLLs in (Firefox) debug builds is bloat only and we should stop doing that, isn't it?

***

http://msdn.microsoft.com/en-us/library/aa985618(v=vs.80).aspx
"Preparing a Test Machine To Run a Debug Executable"
{
Debug versions of Visual C++ library DLLs usually have names that end in "d"; for example, the debug version of the CRT DLL msvcr80.dll is named msvcr80d.dll.

Debug versions of an application are not redistributable and none of the debug versions of the various Visual C++ dynamic-link libraries (DLLs) are redistributable. Debug versions of an application and Visual C++ libraries can only be deployed to another computer internal to your development site for the sole purpose of debugging and testing your application on a computer that does not have Visual C++ 2005 installed.

Install a particular Visual C++ assembly as a private assembly for the application using files provide in the Program Files\Microsoft Visual Studio 8\VC\Redist\debug_nonredist\ directory.
}

http://msdn.microsoft.com/en-us/library/ms235291(v=vs.80).aspx
"How to: Deploy using XCopy"
{
Deploying Visual C++ library DLLs as private assemblies

Debug versions should only be deployed as private assemblies; see the next procedure for more details.

...

For debug applications, use debug DLLs from \vc\redist\debug_nonredist\.
}

2-
There seems to be 3 ways to handle this:

2a-
We should not make MSVC debug builds available at all, even without any MSVC (debug) DLLs.
(Considering that a zip download by a developer/tester is not allowed.)

2b-
Current situation: debug builds are made available but without MSVC debug DLLs.
(This case is a 50-50%...)

2c-
We should package MSVC debug DLLs with our debug builds.
(Considering that "[Mozilla] development site" extends to its development community members, who are the ones likely to ever download debug builds (zip).)

Iiuc, it looks like we should switch from 2b to either 2c or 2a.
Comment 1 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-04-17 17:43:18 PDT
1. Yes, we should stop shipping a release CRT in debug builds.

2a. There's no real point to not putting the builds up for those that do have the right compiler installed.

2c. I'd love to do this, but I'm 99% sure we can't do that legally.
Comment 2 Serge Gautherie (:sgautherie) 2011-04-17 19:22:07 PDT
Created attachment 526649 [details] [diff] [review]
(Av1) In debug builds, don't warn nor package
[Checked in: Comment 7]

(In reply to comment #1)
> 1. Yes, we should stop shipping a release CRT in debug builds.

Fix this part, at_least/ftb.

Ftr, 2 other ways to code this would be to unset or not_subst WIN32_REDIST_DIR.
Comment 3 Serge Gautherie (:sgautherie) 2011-04-17 19:33:32 PDT
(In reply to comment #1)

> 2a. There's no real point to not putting the builds up for those that do have
> the right compiler installed.

As a (community) developer/tester, I can only agree.

But, on a legal p-o-v, I wonder about
"Debug versions of an application are not redistributable".

> 2c. I'd love to do this, but I'm 99% sure we can't do that legally.

I'd love this too.

Who can give legal answers (on behalf of Mozilla)?
Comment 4 Ted Mielczarek [:ted.mielczarek] 2011-04-18 08:27:34 PDT
We're shipping the release CRT DLLs with our debug builds? Yeah, we should stop doing that. I don't think we can do anything else. The debug CRT is non-redistributable, full-stop. Putting them on our FTP site would be redistributing them. IANAL, but I think asking one would be wasting their time. We're not going to stop uploading debug builds, they're useful for other things, and useful for people that do have Visual C++ installed.
Comment 5 Serge Gautherie (:sgautherie) 2011-04-19 06:34:38 PDT
/firefox/tinderbox-builds/mozilla-2.0-win32-debug have this bug too.
Comment 6 Serge Gautherie (:sgautherie) 2011-04-22 10:48:33 PDT
Comment on attachment 526649 [details] [diff] [review]
(Av1) In debug builds, don't warn nor package
[Checked in: Comment 7]

"approval-mozilla-aurora=?":
Save uselessly copying+packaging 1,5 MB in Windows debug builds. No risk.
Comment 7 Serge Gautherie (:sgautherie) 2011-04-22 10:49:38 PDT
Comment on attachment 526649 [details] [diff] [review]
(Av1) In debug builds, don't warn nor package
[Checked in: Comment 7]

http://hg.mozilla.org/mozilla-central/rev/04ff8049cd9a
Comment 8 Ted Mielczarek [:ted.mielczarek] 2011-04-22 12:25:50 PDT
Comment on attachment 526649 [details] [diff] [review]
(Av1) In debug builds, don't warn nor package
[Checked in: Comment 7]

I'll save Aurora drivers the trouble. Serge: part of the "faster release cadence" model means we don't take anything but feature disabling or regression fixes on aurora. We're not landing trivial cleanup patches there, especially something like this that has zero benefit to release builds.
Comment 9 Serge Gautherie (:sgautherie) 2011-04-22 16:22:28 PDT
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1303493910.1303500915.774.gz
WINNT 5.2 mozilla-central leak test build on 2011/04/22 10:38:30
{
/pub/firefox/tinderbox-builds/mozilla-central-win32-debug/1303493891
}

V.Fixed
Comment 10 Serge Gautherie (:sgautherie) 2011-04-22 16:44:10 PDT
(In reply to comment #0)
> Ben, could you tell us where the Firefox WIN32_REDIST_DIR setting comes from?

I filed bug 652263.


(In reply to comment #8)
> Serge: part of the "faster release
> cadence" model means we don't take anything but feature disabling or regression
> fixes on aurora.

Noted, thanks.

Note You need to log in before you can comment on or make changes to this bug.