426887 - automatically set WIN32_REDIST_DIR in configure script if visual-studio path is known

Status: RESOLVED DUPLICATE of bug 679359

(Firefox Build System :: General, enhancement)

Description

[James Schneider]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: not applicable

How to accomplish this manually is explained in:

http://developer.mozilla.org/en/docs/VC8_Build_Instructions ::  Creating a Redistributable

I talked to Ted and he suggested that the './configure' build step could be made to set WIN32_REDIST_DIR variable (if a variable for the visual-studio path is set) so that developers don't have to worry about this step in the future.  (Ben's MozillaBuild project has bash/xterm startup scripts that set the VS paths and other environment settings to appropriate defaults.)

---

Further ideas:

If developers might want to build xulrunner without making it redistributable, (only for local testing use, lets say) then a flag could be added to ./configure that would disable this behavior, e.g. "--without-win32-redistributables".

For completeness sake, some might benefit if ./configure could take a '--with-win32-redistributables=[win32_redist_path]' so that the path could be set explicitly in the '.mozconfig' using an 'ac_add_options' directive.

Reproducible: Always

Steps to Reproduce:
1. Build xulrunner without setting WIN32_REDIST_DIR.
2. Distribute the resulting xulrunner to your friends.
3. Become the laughing-stock.
Actual Results:  
Sad face.

Expected Results:  
see summary

Comment 1

[Benjamin Smedberg]

I WONTFIXed a similar bug a while back: redistributing the MSVC runtime makes you subject to a license that is more restrictive than the MPL, so I don't think we should do it by default but rather require people to opt-in.

Comment 2

[(not currently active) Ted Mielczarek]

It also makes your builds hard to use though :-/

Comment 3

[James Schneider]

Ben: I understand your concern.

I imagine reasoning the reaches the opposite conclusion.  This is probably a discussion that has been had many times, so ignore me if I rehash.

My thought on this matter is that a xulrunner build cannot be considered redistributable unless the visual-studio redistributable package is included.  That means that third-party xulrunner application developers have to either:
 - have users who already have the redistributables,
 - instruct their users to install the redistributables themselves,
 - or have to distribute the redistributables packaged-in or in-parallel with their application.

Knowing that application users must become subject the MS license terms (one way or another), most developers would be happy to furnish the pieces necessary for a fully functional application (even if those license terms come along for the ride).  Further, most windows users have already agreed to significantly more restrictive license terms for the rest of their platform.

The taint that the MS license brings to the application is unavoidable for windows-based xulrunner applications (until someone translates the build process to cross-compile for windows out of a fully open-license-compliant platform).  (Or React/Wine produce replacements.) But the terms of the license do not affect the license terms that might be desired for a developer's own work.  I.e. the non-MS portions of the xulrunner platform or to the application code (XUL and JS) that make it run.  The taint only applies to the final application distributable, for which it is necessary.

Maybe what I mean is actually this: if you build it and distribute it, you must accept MS restrictions because the app will not work without components to which such restrictions necessarily apply.  If you do not plan to distribute, all additional license terms are arguably impotent.

Do I misread the situation?

Hmm... now that I've trotted out the whole thing, I still see that the actual distributable is still covered by a license that is more restrictive and, thus, the mechanism for meaningfully carrying open-licensed material is diseased: the distributable cannot be as free as the code can be.

But the code can still be free.  And it won't run without MS licensed garbage.  It looks like there is some honest room for disagreement here.

Maybe a good compromise would be to make the build process accept ac_add_options to include the redistributables in the build and recommend (with reservations) that developers use the option in relevant wiki documentation.

And then you are back to where we are now, only with slightly better automation.  It would be nice if the build script would warn you that the build was not made properly distributable, though....

Comment 4

[Serge Gautherie (:sgautherie)]

Duplicate of bug 679359 (which has a patch)?