Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PyInstaller for Windows #23

Open
Laberbear opened this issue Feb 21, 2017 · 1 comment
Open

PyInstaller for Windows #23

Laberbear opened this issue Feb 21, 2017 · 1 comment
Assignees

Comments

@Laberbear
Copy link
Member

I'm now working on the PyInstaller integration.
Progress will be posted here.
Right now I discovered, that first of all we can only build on Python 3.5 since 3.6 is not yet supported, which is alright.
Also we probably need to add some code that notifies pyinstaller of the used python modules since the normal analysis only searches for imports (and we are using the import module and not the statement)

@Laberbear Laberbear added this to the initial-release milestone Feb 21, 2017
@Laberbear Laberbear self-assigned this Feb 21, 2017
@Laberbear
Copy link
Member Author

Laberbear commented Feb 24, 2017

There were several issues with the building, but most of it is now fixed.

  • Building in Appveyor specifically means MSBUILD stuff, which we don't use
  • Python Versions >= 3.5 do not seem to work with PyInstaller on the AppVeyor VMs
  • PyInstaller created executables do not seem to use the Python --file-- variable for the executable position and sys.executable has to be used in app path finding
  • stupid issue was detected, where the topmost folder of the software had to be called "app" or the get_path_to_app function would get stuck in an infinite loop
  • the inclusion of the PythonNET module and OpenHardwareMonitor assembly requires the existence of an *.exe.config file of the main executable that contains XML data to allow for remote assembly loading
  • each build in the build matrix triggers a deploy since the whole commit is tagged for building
  • using a defined release name on the appveyor deploy creates a new release and tags the specific commit related to the build. This causes another build to be created and would produce and infinite loop

The scripts now successfully create builds when commits are tagged. The releases are given the name of the tag and if they already exist (created by Travis for example) they'll just get updated with the Windows binaries.
The changes are currently in the test-appveyor branch and will be integrated into master soon(TM)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant