Community:SummerOfCode14:Brainstorming: Difference between revisions

Community:SummerOfCode14:Brainstorming (view source)

Revision as of 10:46, 26 February 2014

297 bytes removed , 26 February 2014

→‎Build system

Manishearth

7

edits

@@ Line 446: / Line 446: @@
 | Inotify/watchman daemon for mach
 | '''Issues to be solved'''
-* <code>./mach build</code> is slow
+* <code>./mach build</code> is slow unless you specify a list of changed files
 * <code>hg qref</code> is slow
 * <code>./mach build</code> does not always work when applied to a single file for incremental. Some js/xul files need a build of the folder or parent folder.
@@ Line 452: / Line 452: @@
 Using inotify or watchman, keep track of the files being changed in the source dirs. This can be done in two ways:
-Directly integrate it with mach and provide it with a mode where it reads the last-updated files from a log of the daemon. Possibly provide a separate but similar system for qref
+Directly integrate it with mach and provide it with a mode where it reads the last-updated files from a log of the daemon and builds just those. Or, integrate it with qref (some [https://bitbucket.org/facebook/hgwatchman partial] [http://mercurial.selenic.com/wiki/InotifyExtension solutions] for this already exist), possibly as a Mercurial extension and make hg read the files to be changed from the active patch. This only deals with changes being added, if a patch is popped or a change is removed from a patch, there needs to be a mechanism to notice this as well.
-Or, integrate it with qref (some [https://bitbucket.org/facebook/hgwatchman partial] [http://mercurial.selenic.com/wiki/InotifyExtension solutions] for this already exist), possibly as a Mercurial extension. Now, make hg read the files to be changed from the active patch. This only deals with changes being added, if a patch is popped or a change is removed from a patch, there needs to be a mechanism to notice this as well.
+Further speed improvements can be made using this.
-This will also require the improvement of mach so that it knows when to build a file and when to build a folder. Generally js and xul builds have to be done at the folder level.
-Additional speed and usability improvements to the patching system can be done as well using this.
-'''Benefit'''
-Faster patching, building, and testing, thus saving time.
 Original idea credit: @ckitching