IE packaging fixes - Githubissues

trigger-corp / browser-extensions

Build and run cross-platform browser extensions from one codebase.

Other

312 stars 52 forks source link

IE packaging fixes #20

Closed makern closed 10 years ago

makern commented 10 years ago

This patch does three things

On OSX use the NSIS binaries included in this repository to build he IE installer
Only require signtool if a certificate was actually specified in the config
Use osslsigncode binaries included in this repository on OSX and Linux (commented out)

The last item is commented out because osslsigncode_osx is currently incorrectly linked against /opt/local/lib/libcrypto.1.0.0.dylib which is not part of OSX. Presumably it was built while some third party package manager like homebrew was interfering. The corresponding system library is /usr/lib/libcrypto.dylib and osslsigncode_osx should be rebuilt using it.

patcon commented 10 years ago

:+1: wooo!

makern commented 10 years ago

A small warning regarding the IE builds. While this allows you to package an extension for IE with the prebuilt IE binaries, it's probably not a good idea to distribute these to end users at this point.

You will have to rebuild the IE binaries from source and make quite a few modifications to prevent your binaries from colliding with other extensions based on OpenForge.

Hopefully there can be a general fix for this problem in the future.

patcon commented 10 years ago

Should we start version-controlling some docs with the code? That seems like the sort of insight that should be written down somewhere :)

(not a fan of github-pages tbh, as it decouples the docs from the code by placing them in a separate branch)

ReadTheDocs is meant to build from a docs/ dir, right? Could we repurpose https://forge.readthedocs.org or start a new one with openforge.readthedocs.org?

makern commented 10 years ago

I agree that all the docs from http://legacy-docs.trigger.io/en/v1.4/modules/browser/ should be added to the repository so unrelated stuff can be removed and they can be extended going forward. See also #12.

readthedocs.org seems to be using reStructuredText which is more powerful than Markdown and probably better suited for api documentation aimed at developers.