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
[EventGhost] - MAJOR ENHANCEMENT - Adds x64 builds #321
Open
kdschlosser
wants to merge
2
commits into
EventGhost:master
Choose a base branch
from
kdschlosser:x64-x86-builds
base: master
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a big overhaul. I had to create a mechanism to properly detect Visual C and also detect the installed run time libraries. as well as detect the .NET version and the Windows SDK. It sets all the proper environment variables. It also updates the solution files of the extension dll files so they will build properly using msbuild. I rewrote the appveyor script so it works with build matrix so it now does 2 build jobs one for x86 and one for x64 I moved all of the Powershell code into ps1 files. this is much easier to change if you install the PowerShell plugin for PyCharm. I had to add to the downloads there is no variant of py2exe available for Python 2.7 x64 on pypi So it s downloaded and installed form source forge. I rewrote the download process it now uses jobs so all the downloads run at the same time. and if Stackless finishes it goes on to install it while the other downloads are still running. I added the build of the extensions to the call to distutils.core.setup. this is a step in the right direction for a proper build. I am going to convert the solution files to be directly built by distutils in the future. and not have msbuild run a solution file. I rewrote the portion of the build that does the module detection. I still have not figured out what the purpose to Build Imports is. the actual file it makes never gets imported anywhere. I do feel that we should remove the use of the global module index. it serves no purpose after the update I made for detecting packages. Because of this update it has caused EG to get chunky. so the setup file is no longer 18 meg. it is more along the lines of 24ish i think, This is because more of the standard modules are now included. the detection process i use actually overrides the __import__ then imports one of the required modules like pill. it then logs all of the imports that take place for that module. and based off those imports it iterates over the directory the imported file is located and then proceeds to import those modules. this creates a cascading effect. which then gives us every single module that could possibly be used. we add that with a simple iteration of the python DLL and LIB folder (not site-packages) and we add all of the standard modules that have not been added already.
I managed to get all of the extensions to build properly using only distutils. no need to call msbuild at all and no need to have the program modify solution files. I will be updating this code soon |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a big overhaul. I had to create a mechanism to properly detect Visual C and also detect the installed run time libraries. as well as detect the .NET version and the Windows SDK. It sets all the proper environment variables. It also updates the solution files of the extension DLL files so they will build properly using MSBuild.
I rewrote the AppVeyor script so it works with build matrix so it now does 2 build jobs one for x86 and one for x64 I moved all of the Powershell code into ps1 files. this is much easier to change if you install the PowerShell plugin for PyCharm. I had to add to the downloads there is no variant of py2exe available for Python 2.7 x64 on pypi So it s downloaded and installed form source forge. I rewrote the download process it now uses jobs so all the downloads run at the same time. and if Stackless finishes it goes on to install it while the other downloads are still running.
I added the build of the extensions to the call to distutils.core.setup. this is a step in the right direction for a proper build. I am going to convert the solution files to be directly built by distutils in the future. and not have MSBuild run a solution file.
I rewrote the portion of the build that does the module detection. I still have not figured out what the purpose to Build Imports is. the actual file it makes never gets imported anywhere. I do feel that we should remove the use of the global module index. it serves no purpose after the update I made for detecting packages. Because of this update it has caused EG to get chunky. so the setup file is no longer 18 meg. it is more along the lines of 24ish i think, This is because more of the standard modules are now included. the detection process i use actually overrides the import then imports one of the required modules like pill. it then logs all of the imports that take place for that module. and based off those imports it iterates over the directory the imported file is located and then proceeds to import those modules. this creates a cascading effect. which then gives us every single module that could possibly be used. we add that with a simple iteration of the python DLL and LIB folder (not site-packages) and we add all of the standard modules that have not been added already.