-
Notifications
You must be signed in to change notification settings - Fork 31
Updating Python 3 for all operating systems #51
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
Comments
We should simply drop the explicit Python 3 for Windows. It doesn't matter which Python major version we use, so long as node-gyp is happy to use it. Python runs gyp, which then builds C++ code. I don't think Python 2 or 3 is faster. What's nice is to not have to specify it in our configs at all and use what's shipped with the Microsoft Hosted Agent (Ubuntu/Windows/macOS images from Microsoft). |
I am interested in doing a "simplify the preparation phase" for things like this. The goal: Cut out as many steps as we can and just run on what the image has in it. Give some thought and a reason why each thing that was dropped is okay to drop. Then merge to No promises on when, but I'd like that to be the next main thing I do for this fork. For example: Don't update Node, don't update npm. |
Various experimental branches at my personal fork: https://dev.azure.com/DeeDeeG/b/_build?view=runs&branchFilter=33%2C34 I don't really know if this will work, so I'm not posting them here yet until I feel some solid progress has been identified to post here. But feel free to look at the runs and the respective branches in the mean-time. |
Clang vs GCC benchmarked; Neither necessarily makes faster apps: https://www.phoronix.com/scan.php?page=article&item=gcc10-clang10-x86 I'd strongly rather use GCC for simpler CI. (If we want to know which builds a faster Atom, we'd have to do benchmarks, which would be very difficult to do meaningfully for such a complex app. Keeping in mind it is strictly for compiling the native C++ code of various packages. Electron/Chromium/V8/Node are already pre-compiled for us. The main native code we rely on isn't even compiled within this repo.) Clang and GCC benchmarked by the Alibaba engineering team, similar results as Phoronix: https://www.alibabacloud.com/blog/gcc-vs--clangllvm-an-in-depth-comparison-of-cc%2B%2B-compilers_595309 |
I do not support regressing to GCC. We should even try to use Clang on Windows and macOS, not the other way around! Other than having better runtime performance, Clang has so many more features. In the current CI, we do not install Clang any more. It is included in all the images. There is no need to use gcc. If in any case, GCC performs better, it is because of its highly optimized GNU libraries that it injects in. I do not think that is relevant to the Atom code. |
I prefer GCC, because it is the default. Edit: If Clang happens to be the default on macOS, and I think it is, I have no objection to that. My desire is to use the default compiler on each platform. Performance is quite similar between GCC and Clang in a general sense, so I personally do not believe that Clang is substantially better for this use-case, unless we benchmark Atom or its packages with the different compilers. Or if there are different bugs in the built app based on the given compiler. That said, I don't need to get into a disagreement about it. So long as we can set the compiler to be one of them and find that it always builds correctly, I suppose I can live with either compiler. |
After we merged #46, it is now apparent that only Windows is using python 3. Should not we use python 3 for all operating systems?
https://github.com/atom-ide-community/atom/blob/d87b59bf0fcdabd0a2e330ceaa513bc1ff21e72a/script/vsts/platforms/templates/preparation.yml#L39-L43
@DeeDeeG
The text was updated successfully, but these errors were encountered: