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

Exception during running the command from another folder #92

Closed
havenchyk opened this issue Dec 15, 2015 · 16 comments
Closed

Exception during running the command from another folder #92

havenchyk opened this issue Dec 15, 2015 · 16 comments
Labels

Comments

@havenchyk
Copy link
Contributor

Hi, during running the script not from the folder where electron is located, I've got

makensis: File: "path\to\my\app\*" -> no files found.
Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
   /oname=outfile one_file_only)
Error in script "/tmp/1hyau9no6zxccgo88o8wo.tpl" on line 59 -- aborting creation process

Could you @stefanjudis assist to find the correct place where fix should be added?

@havenchyk
Copy link
Contributor Author

The first issue was on linux, the same i've got on windows today.

makensis: File: "Client\myapp-win32-x64\*" -> no files found.

BTW, the path should be client\myapp-win32-x64\, where first c is small, but stack prints me capitalized value.

@stefanjudis
Copy link
Contributor

Which electron-builder version are you on?

I had a fix about this recently.

@havenchyk
Copy link
Contributor Author

I believe I'm on the latest version.

"version": "2.4.0"

@stefanjudis
Copy link
Contributor

Hmm, the path is coming from here.

https://github.com/loopline-systems/electron-builder/blob/master/cli.js#L34

Maybe you could dig a bit or provide me your detailed config so that I can have a look. :)

@havenchyk
Copy link
Contributor Author

@stefanjudis I found the "normalization" here. It explains the problem with linux, but not with windows.

@stefanjudis
Copy link
Contributor

If you provide me your config I can have a look tonight.

@havenchyk
Copy link
Contributor Author

Sure, I'll provide it later.

BTW, relative path is not working, but with absolute path for appPath everything works fine (after removing _windowsify, of course.

@stefanjudis
Copy link
Contributor

@havenchyk what the state here?

Can you please provide your configs and commands?

@havenchyk
Copy link
Contributor Author

@stefanjudis config is the same like you're using in the readme:

electron-builder \"dist/osx/Loopline Systems.app\" --platform=osx --out=\"dist/osx\" --config=builder.json"

But, I pass this config not via cli.js, but directly to the builder.build, so after _windowsify on appPath, the path is broken.

I can provide PR for it if you would like.

@stefanjudis
Copy link
Contributor

But, I pass this config not via cli.js, but directly to the builder.build, so after _windowsify on appPath, the path is broken.

I don't get that - you're requiring a file that is not public?

@havenchyk
Copy link
Contributor Author

@stefanjudis I'm using electron-builder in the grunt-electron-builder-wrapper. What I do - is

var electronBuilder = require('electron-builder').init();
...

electronBuilder.build(options);

And options have appPath. You've fixed similar issue about a week ago, but only in the cli.js

@stefanjudis
Copy link
Contributor

Mmmmh... I see... Sorry - forgot about the grunt counterpart. And forgot that index.js is also exposed ( the project is lacking documentation for that too ).

but there shouldn't be the need to fix it in several places - the installers itself ( osx & win ) should get the correct paths provided?

appPath should get an absolute path when it's hitting these files.
Or what do you think?

@havenchyk
Copy link
Contributor Author

I think, that this check should be made inside the osx & win for now, look at https://github.com/loopline-systems/electron-builder/blob/master/lib/win.js#L33 if you're on windows, it's ok, but if you're on mac or linux, it's not needed to _windowsify the path.

Also I think that user of the module should be able to pass relative path as well. So we need to do additional check for win and mac:

  • is the appPath absolute?
  • if not, make path.resolve
  • if windows - invoke _windowsify (if it's really needed)

@stefanjudis
Copy link
Contributor

it's ok, but if you're on mac or linux, it's not needed to _windowsify the path.

I needed it in first place and I am on a mac - so I'm not sure about that.

Also I think that user of the module should be able to pass relative path as well

Totally agree on that one. But that doesn't mean we have to treat it in win.js or osx.js. These two files should only accept absolute paths and do there thing with it. We're also avoiding code duplication for path handling.

So about the points:

is the appPath absolute?

This can be done by simply using path.resolve - there is no additional check needed as it's doing that. :)

path.resolve( path.cwd(), '/Users' )
> /Users

path.resolve( process.cwd(), 'foo' )
> /Users/stefan/Sites/perf-tooling/foo

if windows - invoke _windowsify (if it's really needed)

I really would like to double check that. Are you on a mac to prove it?

To sum up - what I'd like to do is checking the path handling in cli.js and index.js to make sure the correct paths hit the platform specific files... Maybe my fix from two weeks ago was not that good. ;)

@havenchyk
Copy link
Contributor Author

I can check only on windows and linux. I'm mostly working on linux, so it was an issue for me.
BTW, if you're on Mac and need _windowsify, there is some misleading in the name.

And yes, appPath should be converted to the absolute before using.

@stefanjudis
Copy link
Contributor

I can check only on windows and linux. I'm mostly working on linux, so it was an issue for me.

Well then PR it - and I'll check it. :)

BTW, if you're on Mac and need _windowsify, there is some misleading in the name.

Well not really - because it will go into wine and NSIS and these want windows paths. :)

stefanjudis added a commit that referenced this issue Dec 22, 2015
Always use absolute appPath. Fixes #92
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants