Make setup.exe compatible with the component build (2nd try).

Make setup.exe compatible with the component build.

The problem with the current component build is that chrome.exe and setup.exe only know to look for DLLs like base.dll in the current directory (except chrome.dll for which they're hardcoded to know where to look). On an install those DLLs are in the version directory so chrome.exe and setup.exe fail to run not finding required DLLs...

To fix this we generate config files (to point in the version directory) and manifests (to list all the DLL dependencies explicitly) to be installed beside the exes.

Each DLL also has a manifest in the version directory to give it an "assemblyIdentity" (i.e. a unique name which is referred to as a dependency by each exe's manifest).

These manifests are called "assembly manifest" and do NOT interfere with the private manifest possibly embedded in each DLL (details here http://msdn.microsoft.com/en-us/library/windows/desktop/aa374219(v=vs.85).aspx)

<dependency> tags then need to be added to chrome.exe.manifest and setup.exe.manifest for each DLL in the version directory it will use (to be safe we make add an entry for all DLLs as there is no downside to referring an unused DLL). In this step, we augment the manifests generated by the build instead of creating new one to make sure any property passed on by the build is kept and that we are only *adding* new functionality without hindering current behavior.


NOTE: This CL doesn't make mini_installer.exe compatible with the component build yet (as mini_installer runs setup.exe right after extracting it and without any other DLLs/manifests beside it).

However it is now possible to use setup.exe (which takes the exact same parameters as mini_installer.exe) from the build output directory with a component build :)!!!

BUG=127233
TEST=Turn on component build with gyp config "component=shared_libary" and make sure we can install chrome with the generated setup.exe.
Make sure we can run the installed Chrome.
Make sure we can uninstall the installed Chrome (i.e. that setup.exe in <version_dir>/Installer is able to find its DLLs).

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=137722

[gab, 2012-05-16 06:13:40]

Switched things around, the only difference as far as the build output is
concerned now is that, in component builds, chrome.exe.manifest and
setup.exe.manifest are not embedded (which simply means that VS drops the final
manifests by the exes instead of embedding them; which provides the same
behavior when ran from the build folder). Everything else is specific to the
archive.

I detailed everything else in the CL description.

There most likely still is a small issue with the CRT DLLs when copying
setup.exe, setup.exe.manifest, and *.dll to another machine, but I will solve
this in another small patch to keep this one clean (and be able to revert the
other one if need be without reverting this one!). One thing for sure this CL
won't trigger the CRT bugs some VS2008 devs were seeing today as the manifests
in the build output folder are identical to the ones that were embedded before.
Literally nothing changed with regards to anything that is not a
component+installer build :).


FWIW, I have learnt a whole lot more than I expected about VS, gyp, Windows
manifests and executables, Event Viewer, etc. doing this. So on top of being
very useful for the team it made me a better Windows hacker woohoo!

[gab, 2012-05-16 06:27:54]

On 2012/05/16 06:13:40, gab wrote:
> Switched things around, the only difference as far as the build output is
> concerned now is that, in component builds, chrome.exe.manifest and
> setup.exe.manifest are not embedded (which simply means that VS drops the
final
> manifests by the exes instead of embedding them; which provides the same
> behavior when ran from the build folder). Everything else is specific to the
> archive.
> 
> I detailed everything else in the CL description.
> 
> There most likely still is a small issue with the CRT DLLs when copying
> setup.exe, setup.exe.manifest, and *.dll to another machine, but I will solve
> this in another small patch to keep this one clean (and be able to revert the
> other one if need be without reverting this one!). One thing for sure this CL
> won't trigger the CRT bugs some VS2008 devs were seeing today as the manifests
> in the build output folder are identical to the ones that were embedded
before.
> Literally nothing changed with regards to anything that is not a
> component+installer build :).
> 

Actually I just tested this and with the augmented manifests built by this patch
I no longer run into the CRT DLL problems I had earlier today, seems like the
WinSxS dependency carried over from the default manifests is sufficient.
Woohoo!!

> 
> FWIW, I have learnt a whole lot more than I expected about VS, gyp, Windows
> manifests and executables, Event Viewer, etc. doing this. So on top of being
> very useful for the team it made me a better Windows hacker woohoo!

[gab, 2012-05-16 06:35:50]

On 2012/05/16 06:27:54, gab wrote:
> On 2012/05/16 06:13:40, gab wrote:
> > Switched things around, the only difference as far as the build output is
> > concerned now is that, in component builds, chrome.exe.manifest and
> > setup.exe.manifest are not embedded (which simply means that VS drops the
> final
> > manifests by the exes instead of embedding them; which provides the same
> > behavior when ran from the build folder). Everything else is specific to the
> > archive.
> > 
> > I detailed everything else in the CL description.
> > 
> > There most likely still is a small issue with the CRT DLLs when copying
> > setup.exe, setup.exe.manifest, and *.dll to another machine, but I will
solve
> > this in another small patch to keep this one clean (and be able to revert
the
> > other one if need be without reverting this one!). One thing for sure this
CL
> > won't trigger the CRT bugs some VS2008 devs were seeing today as the
manifests
> > in the build output folder are identical to the ones that were embedded
> before.
> > Literally nothing changed with regards to anything that is not a
> > component+installer build :).
> > 
> 
> Actually I just tested this and with the augmented manifests built by this
patch
> I no longer run into the CRT DLL problems I had earlier today, seems like the
> WinSxS dependency carried over from the default manifests is sufficient.
> Woohoo!!

Ok, wait, no, I got carried away in my excitement and had the CRT DLLs sitting
in my Debug folder from previous experiments and they got pulled in with the
other DLLs... so of course it "worked" :)! (this however proves that all we need
to do to actually fix the issue is to package those DLLs with the others, patch
on the way!)

> 
> > 
> > FWIW, I have learnt a whole lot more than I expected about VS, gyp, Windows
> > manifests and executables, Event Viewer, etc. doing this. So on top of being
> > very useful for the team it made me a better Windows hacker woohoo!

[gab, 2012-05-16 21:50:21]

https://chromiumcodereview.appspot.com/10399041/diff/8002/chrome/tools/build/...
File chrome/tools/build/win/create_installer_archive.py (right):

https://chromiumcodereview.appspot.com/10399041/diff/8002/chrome/tools/build/...
chrome/tools/build/win/create_installer_archive.py:326: if s.find(insert_before)
!= -1), -1)
I now use a python generator to get the first index that *contains*
|insert_before| as opposed to the first one that perfectly matches (should take
care of silly mismatches caused by endlines, etc.)

[robertshield, 2012-05-17 16:32:55]

lgtm

[commit-bot: I haz the power, 2012-05-17 18:41:00]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/gab@chromium.org/10399041/8002

[commit-bot: I haz the power, 2012-05-17 20:15:13]

Change committed as 137722