##// END OF EJS Templates
packaging: stage files and dynamically generate WiX installer...
packaging: stage files and dynamically generate WiX installer Like we did for Inno, we want to make the WiX installer "dumb" and simply consume source files from a directory tree rather than have to define every single file in installer files. This will greatly decrease the amount of effort required to maintain the WiX installer since we don't have to think that much about keeping files in sync. This commit changes the WiX packager to populate a staging directory as part of packaging. After it does so, it scans that directory and dynamically generates WiX XML defining the content within. The IDs and GUIDs being generated are deterministic. So, upgrades should work as expected in Windows Installer land. (WiX has a "heat" tool that can generate XML by walking the filesystem but it doesn't have this deterministic property, sadly.) As part of this change, GUIDs are now effectively reset. So the next upgrade should be a complete wipe and replace. This could potentially cause issues. But in my local testing, I was able to upgrade an existing 5.1.2 install without issue. Compared to the previous commit, the installed files differ in the following: * A ReleaseNotes.txt file is now included * A hgrc.d/editor.rc file is now generated (mercurial.rc has been updated to reflect this logical change to the content source) * All files are marked as read-only. Previously, only a subset of files were. This should help prevent unwanted tampering. Although we may want to consider use cases like modifying template files... This change also means that Inno and WiX are now using very similar code for managing the install layout. This means that on disk both packages are nearly identical. The differences in install layout are as follows: * Inno has a Copying.txt vs a COPYING.rtf for WiX. (The WiX installer wants to use RTF.) * Inno has a Mercurial.url file that is an internet shortcut to www.mercurial-scm.org. (This could potentially be removed.) * Inno includes msvc[mpr]90.dll files and WiX does not. (WiX installs the MSVC runtime via merge modules.) * Inno includes unins000.{dat,exe} files. (WiX's state is managed by Windows Installer, which places things elsewhere.) Because file lists are dynamically generated now, the test ensuring things remain in sync has been deleted. Good riddance. While this is a huge step towards unifying the Windows installers, there's still some improvements that can be made. But I think it is worth celebrating the milestone of getting both Inno and WiX to essentially share core packaging code and workflows. That should make it much easier to change the installers going forward. This will aid support of Python 3. Differential Revision: https://phab.mercurial-scm.org/D7173

File last commit:

r43346:2372284d default
r44022:94eac340 default
Show More
catapipe.py
121 lines | 3.6 KiB | text/x-python | PythonLexer
#!/usr/bin/env python3
#
# Copyright 2018 Google LLC.
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
"""Tool read primitive events from a pipe to produce a catapult trace.
Usage:
Terminal 1: $ catapipe.py /tmp/mypipe /tmp/trace.json
Terminal 2: $ HGCATAPULTSERVERPIPE=/tmp/mypipe hg root
<ctrl-c catapipe.py in Terminal 1>
$ catapult/tracing/bin/trace2html /tmp/trace.json # produce /tmp/trace.html
<open trace.html in your browser of choice; the WASD keys are very useful>
(catapult is located at https://github.com/catapult-project/catapult)
For now the event stream supports
START $SESSIONID ...
and
END $SESSIONID ...
events. Everything after the SESSIONID (which must not contain spaces)
is used as a label for the event. Events are timestamped as of when
they arrive in this process and are then used to produce catapult
traces that can be loaded in Chrome's about:tracing utility. It's
important that the event stream *into* this process stay simple,
because we have to emit it from the shell scripts produced by
run-tests.py.
Typically you'll want to place the path to the named pipe in the
HGCATAPULTSERVERPIPE environment variable, which both run-tests and hg
understand. To trace *only* run-tests, use HGTESTCATAPULTSERVERPIPE instead.
"""
from __future__ import absolute_import, print_function
import argparse
import json
import os
import timeit
_TYPEMAP = {
'START': 'B',
'END': 'E',
'COUNTER': 'C',
}
_threadmap = {}
# Timeit already contains the whole logic about which timer to use based on
# Python version and OS
timer = timeit.default_timer
def main():
parser = argparse.ArgumentParser()
parser.add_argument(
'pipe',
type=str,
nargs=1,
help='Path of named pipe to create and listen on.',
)
parser.add_argument(
'output',
default='trace.json',
type=str,
nargs='?',
help='Path of json file to create where the traces ' 'will be stored.',
)
parser.add_argument(
'--debug',
default=False,
action='store_true',
help='Print useful debug messages',
)
args = parser.parse_args()
fn = args.pipe[0]
os.mkfifo(fn)
try:
with open(fn) as f, open(args.output, 'w') as out:
out.write('[\n')
start = timer()
while True:
ev = f.readline().strip()
if not ev:
continue
now = timer()
if args.debug:
print(ev)
verb, session, label = ev.split(' ', 2)
if session not in _threadmap:
_threadmap[session] = len(_threadmap)
if verb == 'COUNTER':
amount, label = label.split(' ', 1)
payload_args = {'value': int(amount)}
else:
payload_args = {}
pid = _threadmap[session]
ts_micros = (now - start) * 1000000
out.write(
json.dumps(
{
"name": label,
"cat": "misc",
"ph": _TYPEMAP[verb],
"ts": ts_micros,
"pid": pid,
"tid": 1,
"args": payload_args,
}
)
)
out.write(',\n')
finally:
os.unlink(fn)
if __name__ == '__main__':
main()