145
edits
Penelope Developer Page: Difference between revisions
Jump to navigation
Jump to search
Added Windows build instructions
(Information on Building) |
(Added Windows build instructions) |
||
| Line 59: | Line 59: | ||
ac_add_options --with-branding=other-licenses/branding/eudora | ac_add_options --with-branding=other-licenses/branding/eudora | ||
== Building Thunderbird on Windows == | |||
See the steps above under Linux for how to get the source code via CVS. | |||
Penelope uses the version of the Mozilla platform before it switched to using the MozillaBuild environment. Make sure you go through in detail the [http://developer.mozilla.org/en/docs/Windows_build_prerequisites_using_cygwin setup documentation for Cygwin]. There's lots of environment variables to create and some tools to download and configure. They recommend having a batch script to set up the environment, but you can permanently set all the environment variables so that you can compile from any command prompt and don't have to remember to run the script. | |||
The Windows build prerequisites result in a setup that will not build. The current version of the "ash" component ("Base" category) is 20040127-3. This version is not compatible with the current Mozilla build - you need to go back to 20040127-1. As it turns out, there is only one file in the "ash" package that seems to make a difference in the build: sh.exe. | |||
Here's the options for your %HOME%\.mozconfig file in order to make a debug build: | |||
. $topsrcdir/mail/config/mozconfig | |||
ac_add_options --disable-optimize | |||
ac_add_options --enable-debug | |||
ac_add_options --disable-static --enable-shared | |||
ac_add_options --disable-tests | |||
ac_add_options --enable-extensions=default,penelope | |||
Finally, go to the root of the source tree and do a: | |||
* make -f client.mk build | |||
=== Visual Studio .NET 2003 and Service Pack 1 === | |||
You must install Service Pack 1 in order to successfully build. You can find Service Pack 1 [http://www.microsoft.com/downloads/details.aspx?familyid=69d2219f-ce82-46a5-8aec-072bd4bb955e&displaylang=en here]. There's one aspect to installing the Service Pack that can be somewhat tricky. At a point during the install of the Service Pack it will ask you for the <code>vs_setup.msi</code> file of the original Visual Studio installer. You must have the exact original installer that you personally used, otherwise the Service Pack upgrade won't continue on. The Service Pack installer is woefully slow, and has bad UI as well. Know that if you run it there will be places where there are long pauses (I had one that was around 15 minutes). The release notes for the SP [http://support.microsoft.com/default.aspx?scid=kb;en-us;924009#70 detail this]. | |||
=== Windows Vista === | |||
Windows Vista provides some roadblocks in compiling Thunderbird. The first is the new security model. By default, administrator accounts under Vista run applications at a reduced privilege level called Standard User. Microsoft found that the most common legitimate reason to need administrator rights was when installing an application, and in order for all the existing installation programs to work under Vista they had to come up with a heuristic workaround. What Vista does is automatically attempt to elevate the privilege of any application that has the words "install" or "setup" in the name of the executable filename. I say "attempt" because there appear to be some situations where the privilege elevation fails, and one of those happens to be when called inside of scripts. I think it has to do with the way the process is created (privilege elevation happens when you call ShellExecute(), but not when CreateProcess() is used), but I'm not sure of that entirely because I don't know how Cygwin shells start up new processes. | |||
And wouldn't you know it, one of the utilities used to compile Thunderbird falls in to this heuristic: nsinstall.exe. All that command-line tool really does is copy some files, which doesn't require Administrator privileges as long as you have have write access to the destination directory, but Vista's automatic privilege elevation thinks it might due to the name. The privilege elevation fails and so the build fails. Happy, happy, joy, joy. | |||
There's two current workarounds. One is that the Command Prompt window that you use to compile Thunderbird can be run as Administrator. You can create a shortcut setting that up (its in the Properties, Compatibility tab), or you can right-click on a link to a Command Prompt (e.g. one that shows up on the Start menu) and select "Run as Administrator". This is an unsatisfying solution because it raises the privilege level unnecessarily, but it does work. It does happen to solve other permission-related issues with files in general, so it is an easy way to fix the problem. It's also no different than the security model of Windows before Vista (well, at least the way that most people set it up, which is to run as Administrator all of the time). | |||
The other way is to tell Vista that the app doesn't really need Administrator privileges. You can do this via a manifest file, which is an XML file which has properties about the application. It has the same name as the executable (including the ".exe"), but with an extra extension of ".mainfest" to it. The manifest file contents should look like this: | |||
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> | |||
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> | |||
<assemblyIdentity version="1.0.0.0" | |||
processorArchitecture="X86" | |||
name="nsinstall" | |||
type="win32"/> | |||
<description>Description of your application</description> | |||
<!-- Identify the application security requirements. --> | |||
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> | |||
<security> | |||
<requestedPrivileges> | |||
<requestedExecutionLevel | |||
level="asInvoker" | |||
uiAccess="false"/> | |||
</requestedPrivileges> | |||
</security> | |||
</trustInfo> | |||
</assembly> | |||
The pertinent part that makes it work is the <code>level="asInvoker"</code> attribute, which tells Vista that it doesn't need any extra privileges to run. There's one snag to this, which is that if you've already run nsinstall.exe without the .manifest file, then Vista has already put the perceived needed privilege elevation in the [http://blogs.msdn.com/vistacompatteam/archive/2006/11/13/manifest-and-the-fusion-cache.aspx fusion cache]. In order to clear the cache you need to reboot Vista. | |||
There is a third way to workaround the problem, but I don't like the long-term implications of it. You could rename the nsinstall.exe utility to something that doesn't have "install" or "setup" in the name and then change the build scripts to that effect. However, that means keeping a branch of the build scripts forever and that would probably cause more headaches down the road. | |||
== Reducing Build Time == | == Reducing Build Time == | ||