Currently, `scripts/unix/electron-download-package.sh` contains its own
logic to determine if the package was already downloaded.
This commit takes the electron package uncompressing task to the
configure scripts, and reduce `electron-download-package.sh` to a script
that simply downloads the zip to a certain location, since this change
allows us to have a separate Make rule to download the Electron zip (and
thus have Make take care of caching).
After this change, the `electron-configure-package-*.sh` scripts are no
longer routines that modify a certain directory, but scripts that take
the zip as an input and actually create the package directory, which
aligns better with Make's design.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently, we create a "resources app" and install dependencies on it.
This means that to create another "resources app", the whole dependency
installation process needs to be repeated.
As a solution, we cache dependencies at
`release/electron-$(TARGET_PLATFORM)-$(TARGET_ARCH)-dependencies/` and
copy them to the resources apps as we need them.
This has the additional benefit that the resources app depends on the
dependencies rather than the other way around (dependencies depend on
the resources app), which didn't feel right.
In order to accomodate to these changes, the dependencies scripts are
now in charge of taking their corresponding manifests with them when the
prefix option is passed, given that neither `npm` nor `bower` allow to
customise the output location.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Additionally, we setup an EditorConfig rule to automatically switch to
tab style on Makefile.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This Makefile ties together all the build scripts we've been developing
so far. It currently only supports UNIX based operating systems, but
Windows support will be added soon.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
With the addition of native addons to Etcher, its no longer possible to
package the application for all operating system in a single host.
Given we need to build on Windows, we're creating cross-platform bash
and batch scripts and deprecating the original Makefile.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
By locking the electron version in `package.json`, we can require it
from the Makefile to ensure production and development are both running
the exact same electron version, and ensures they don't easily get out
of sync.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
* Upgrade Electron to v0.37.6
The main motiviation for such upgrade is that an error manifesting
itself as `Cannot read property 'object' of undefined` on certain Linux
systems was fixed in v0.37.4.
See https://github.com/electron/electron/issues/5229
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
* Make use of shell module by requiring `shell`
Otherwise we get a strange issue when trying to stub it:
TypeError: Attempted to wrap undefined property openExternal as function
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
This is useful to prompt the user to install the `.desktop` file.
The `Description` key in `Etcher.desktop` was changed to `Comment` since
`desktop-file-validate` complained with:
Etcher.desktop: error: file contains key "Description" in group "Desktop
Entry", but keys extending the format should start with "X-"
After checking the desktop file format specification, the correct key
should be "Comment"
(https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html).
See: bc6e519964 (commitcomment-17164442)
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
This PR fixes a frequent issue users were having where opening
`Etcher.app` would result in:
"Etcher.app" is damaged and can't be opened. You should move it to
the trash.
Checking the code-signature of the application returned the following
error message:
$ spctl -a -v Etcher.app
Etcher.app: invalid signature (code or signature have been modified)
The solution is based on the following paragraphs from Apple's "OS X
Code Signing in Depth" technical note:
https://developer.apple.com/library/mac/technotes/tn2206/_index.html
> Code signing uses extended attributes to store signatures in non-Mach-O
> executables such as script files. If the extended attributes are lost
> then the program's identity will be broken. Thus, when you ship your
> script, you must use a mechanism that preserves extended attributes.
>
> One way to guarantee preservation of extended attributes is by packing
> up your signed code in a read-write disk image (DMG) file before signing
> and then, after signing, converting to read-only. You probably don't
> need to use a disk image until the final package stage so another less
> heavy-handed method would be to use ZIP or XIP files.
In summary, what we now do is:
- Create a temporal read-write DMG image.
- Perform the code-signing *inside* the DMG image.
- Convert the temporal DMG image into a compressed read-only image.
Sadly, this custom workflow doesn't fit in `electron-packager` nor
`electron-builder`, so we had to re-implement the features those
packages provide us in a nice encapsulated way ourselves.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
The `bluebird` module contains a directory called "release", which gets
omitted by `electron-packager`.
After some experimentation, there doesn't seems to be a way to make
`electron-packager` ignore a pattern only on the current directory,
therefore we change the name of our output directory to something that
can't possibly collide with something else.
