If node is already in PATH and functional, we don't need to spend a
bunch of time running all of Boxen's setup scripts.
This reduces clean build time on my MacBook Pro from 46 seconds to 31
seconds.
Instead of finding and compiling all .coffee/.cson files in
script/copy-files-to-bundle, we now tell gyp how to do this for us. It
works like this:
1. Rakefile invokes the new script/generate-sources-gypi script to
generate sources.gypi. This file lists all the .coffee/.cson files in
the src, static, and vendor directories, as well as a new
compiled_sources_dir variable that specifies where the compiled
versions of the files should be placed.
2. atom.gyp includes sources.gypi.
3. atom.gyp has a new target, generated_sources, which contains all the
.coffee/.cson files, and uses two rules to tell gyp how to compile
them. The rules invoke the new script/compile-coffee and
script/compile-cson files once for each file.
4. gyp generates one Makefile for each rule to actually perform the
compilation.
5. script/copy-files-to-bundle now takes the compiled_sources_dir
variable as an argument, and copies files both from there and from
the repository into the Resources directory.
By putting the compilation into a different target, we can do it in
parallel with compiling/linking our binaries. And gyp automatically runs
make using -j$(sysctl -n hw.ncpu), so compilation of .coffee/.cson files
happens in parallel, too.
These changes reduce clean build time on my MacBook Pro from 55 seconds
to 46 seconds.
This is a workaround for
<http://code.google.com/p/gyp/issues/detail?id=323>.
A future change will cause gyp to generate Makefiles to compile
.coffee/.cson files to .js/.json. Makefiles use # as the comment
character, and gyp isn't smart enough to escape the #. So now we don't
use # in filenames to work around this bug.
This forces the object to be interpreted as the
second argument to the callWorkerMethod function
instead of as the first argument to function returned
from callWorkerMethod.
Closes#338
stringByStandardizingPath has an interesting quirk that causes it to
remove `/private` from the path if the result still indicates an
existing file or directory
All our native code now gets built into Atom.framework. Atom.app and
Atom Helper.app both link against this framework. All resources other
than a couple of main-bundle-only ones (e.g., atom.icns) go into
Atom.framework.
Note that this means that there's no compile- or link-time separation
between main process code and helper process code. We could introduce a
compile-time separation by building main process and helper process code
into separate static libraries with mutually exclusive include paths, if
we want.
Atom.framework exports a single symbol: AtomMain(). Atom.app and Atom
Helper.app contain a single source file: main.cpp. main() just calls
AtomMain().
All frameworks are placed in Atom.app/Contents/Frameworks. We now link
against all frameworks using @rpath-based install names, which allows
Atom.app and Atom Helper.app to find them automatically based on their
own LD_RUNPATH_SEARCH_PATH settings. We use install_name_tool at build
time on each of our three binaries (Atom.app, Atom Helper.app,
Atom.framework) to set the install names.
By reducing duplication of code and resources between Atom.app and Atom
Helper.app (and the EH/NP copies of Atom Helper.app), this reduces the
size of the total installed Atom.app bundle from 145MB to 82MB. By
compiling .coffee and .cson files only once, clean build time drops from
114 seconds to 79 seconds on my MacBook Pro.
Previously readtags.c was not checking if the
end pattern / was preceded by an escaped \
which would cause segmentation faults for patterns
that ended with an escaped \.
