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

Develop command working on Windows again #47

Closed
wants to merge 5 commits into from

Conversation

chrisreedio
Copy link
Contributor

The latest build had broken the develop command on Windows for @fadeaway and myself.
The develop command should take the current OS / arch into account since it will be running locally on that system.
The build scripts pass in flags to override the target platform/arch.

  • Added single quote to editor config

Currently on Windows we the native:serve works everytime and the build is 'working' with no errors but we never see a dist directory or output files.

That was the case before the work in this PR so there must still be something going on.

The prior work had broken the develop command on Windows.
The develop command should take the current OS / arch into account since it will be running locally on that system.
The build scripts pass in flags to override the target platform/arch.

* Added single quote  to editor config
@@ -7,6 +7,8 @@ indent_size = 4
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true
quote_type = single
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VSCode kept wanting to put double quotes which was against the current style of this repo so I added this until we have styleci setup

@@ -7,6 +7,8 @@ indent_size = 4
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true
quote_type = single
max_line_length = 120
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may also be controversial but again, it kept most lines as they were and until we get styleci setup, it should help.

let phpBinaryFilename = 'php';
if (isWindows) {
// Default to the current platform for develop mode. Build will pass in an arg that overrides this
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aligns the target with the directory structure.

let phpBinaryFilename = 'php';
if (isWindows) {
// Default to the current platform for develop mode. Build will pass in an arg that overrides this
let targetOs = process.platform;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Set the target to the current OS, if building, an override flag will be sent in.

targetOs = 'win';
phpBinaryFilename += '.exe';
}
if (isLinux) {
} else if (isLinux) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These else-if blocks seem redundant now (not the first one as it's setting the binary filename)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The switch normalizes the targetOs from process.platform, the if statements handle the override flags passed in during build stages.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chrisreedio Just note when it is Linux, but also Win32... at the same time. (Ubuntu in WSL in Windows)

https://github.com/NativePHP/electron/issues/50

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't believe you'd get that as the process.platform will always be the actively running platform. So if running it in WSL, it'd be Linux and if running in powershell (et al) it'd be win32 which gets converted to 'win' for the bin directory lookup.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I run WSL in Windows 10 and have been working with NativePHP from Windows itself. In the long run, I'd prefer to work in WSL and build for Windows.

Note that only Windows 11 allows graphical WSL (linux apps). If in windows 10, the native:develop command has to be run from Windows (not WSL (for now)).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you rename the variables in this case?
I think isWindows, isLinux etc is confusing. It's more like "forcedOS" right? Maybe we can simplify this a bit.

@chrisreedio
Copy link
Contributor Author

chrisreedio commented Jul 29, 2023 via email

binaryArch = 'x64';
} else if (isDarwin) {
binaryArch = 'x86';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll update the php-bin package so that the mac binaries are all in an x64 folder. I think it was just an error on my end and it should be like that anyway. Then we can get rid of this macOS specific check.

@StoneyEagle
Copy link

I got to get the Electron app to install the php dependencies.
By prefixing them with npx and node, windows will properly execute the scripts and not open the electron-builder.js file.

vendor\nativephp\electron\resources\js\package.json

{
  "scripts": {
    "dev": "npx electron-vite dev --watch",
    "postinstall": "node electron-builder install-app-deps",
}

@chrisreedio
Copy link
Contributor Author

I got some more done on this today but had some life stuff and wasn't able to get finished. Will do my best to get the rework on this pushed by end of day for me tomorrow. (around 24h from now)

Also added some styling config to editor config that matches the existing code style.
This of course will be a moot point once have style CI setup.

* Added single quote to editor config
* Building for windows in the develop command.
* minor logic corrections
* Fixed platform names
* Tidied up the build target selection code in electron-builder.js
@chrisreedio
Copy link
Contributor Author

I saw this as a merge conflict in the yarn.lock

<<<<<<< main
"@esbuild/win32-x64@0.18.17":
  version "0.18.17"
  resolved "https://registry.npmjs.org/@esbuild/win32-x64/-/win32-x64-0.18.17.tgz"
  integrity sha512-fGEb8f2BSA3CW7riJVurug65ACLuQAzKq0SSqkY2b2yHHH0MzDfbLyKIGzHwOI/gkHcxM/leuSW6D5w/LMNitA==
=======
"@esbuild/darwin-arm64@0.18.17":
  version "0.18.17"
  resolved "https://registry.npmjs.org/@esbuild/darwin-arm64/-/darwin-arm64-0.18.17.tgz"
  integrity sha512-M9uJ9VSB1oli2BE/dJs3zVr9kcCBBsE883prage1NWz6pBS++1oNn/7soPNS3+1DGj0FrkSvnED4Bmlu1VAE9g==
>>>>>>> main

I went with the Darwin one to be safe but I don't remember swapping this out.

Maybe @mpociot or someone can advise and double check me on this?


I still have yet to get the build command on Windows to create a dist directory much less place any output files into it.

@fadeaway looked at this at length too and was unsure how to get it working.

I can can revisit this in the coming days. This at least gets the development working well within Windows itself (not WSL).

Removed added space from merge conflict.
@CharlieEtienne
Copy link

Hi, I think I get this behaviour on Windows (no dist folder created and no .exe). See #177

I tried to replace my files with these commits changes, but I still don't have a dist folder after building.

I also tried different fixes found on other issues, but nothing does the trick for my case...

@mpociot
Copy link
Member

mpociot commented Oct 18, 2023

Alright...I just checked this PR again and the latest changes fixed the develop command on Windows already which is why I'm closing this.
Thank you for your PR!

@mpociot mpociot closed this Oct 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants