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

Organize dist directory to be uniform for all platforms #670

Closed
Mercieral opened this issue Aug 15, 2016 · 10 comments
Closed

Organize dist directory to be uniform for all platforms #670

Mercieral opened this issue Aug 15, 2016 · 10 comments

Comments

@Mercieral
Copy link

Mercieral commented Aug 15, 2016

  • Version: latest
  • Target: All

This is a small suggestion to organize the dist directory to make it a little more clean when building for multiple platforms. When I build with build -mlw, It looks something like...

./dist
|── myApp-0.1.0-x86_64.AppImage <packed linux>
|── linux
       |── <unpacked linux app files?>
|── mac
       |── myApp.app <unpacked mac>
       |── myApp-0.1.0.dmg <packed mac>
       |── <other various mac related files (zip, LICENSE)>
|── win
      |── myApp Setup 0.1.0.exe <packed win>
      |── <Other win related files>
|── win-unpacked
      |── myApp.exe <unpacked win>
      |── <unpacked win app files> 

To clarify, each platform's output directories are currently organized differently which could be confusing.

  • Linux-packed is directly in the dist directory, linux-unpacked (?) is in the dist/linux directory
  • mac-packed and unpacked are both in dist/mac
  • win-packed is in win and win-unpacked is in win-unpacked.

I'm suggesting, for easier viewing and grabbing of specific platform files, to have something more uniform such as this

./dist
|── linux
       |── linux-packed
                |── myApp-0.1.0-x86_64.AppImage <packed linux>
       |── linux-unpacked
                |── <unpacked linux app files?>
|── mac
       |── mac-packed
                |── myApp-0.1.0.dmg <packed mac>
       |── mac-unpacked
                |── myApp.app <unpacked mac>
       |── <other various mac related files (zip, LICENSE)>
|── win
       |── win-packed
                |── myApp Setup 0.1.0.exe <packed win>
                |── <Other win related files>
       |── win-unpacked
                |── myApp.exe
                |── <unpacked win app files> 

Thoughts/opinions?

I may be able to figure it out and make a PR on my own time, but I wanted to get an opinion first.

@develar
Copy link
Member

develar commented Aug 16, 2016

NSIS and all Linux targets produces artifacts to ./dist. Do you like it? Or per os (as you proposed — linux, mac, win) is better for "viewing and grabbing"?

@Mercieral
Copy link
Author

Mercieral commented Aug 16, 2016

Ah I see why NSIS and linux targets are produced directly to ./dist as they are one file, which is great if you are building just one OS. This would reduce the amount of clicking required to get to the file you need too.

However when building for multiple OS, the inconsistencies make the ./dist directory disorganized and (somewhat) confusing to traverse through. With the structure I suggest, if say the user develops on Mac and wants to put the Linux and windows artifacts on an external drive to transfer to a different machine, all they would have to do is select those two directories and copy them.

@develar
Copy link
Member

develar commented Aug 16, 2016

user develops on Mac and wants to put the Linux and windows artifacts on an external drive to transfer to a different machine

BTW, Parallels Desktop allows you to use "Open in Windows" or "Reveal in Windows". And share mac home to Linux if need.

@develar
Copy link
Member

develar commented Aug 16, 2016

Only, only Squirrel.Windows target creates directory for packed because of *** RELEASES file. It the only reason.

Mac — historically. Can be flattened as well (i.e. as NSIS/Linux).

With the structure I suggest

I don't like it, but... I don't have yet final opinion. In any case it doesn't matter — you should not publish it manually — open PR instead (bintray publisher coming soon).

@develar
Copy link
Member

develar commented Aug 18, 2016

linux can be renamed to linux-unpacked for consistency. But I don't like idea to create special linux directory just for several files — .AppImage or .snap.

@Mercieral
Copy link
Author

linux can be renamed to linux-unpacked for consistency

That is fair enough. Even just more consistent naming would make it clearer to the user.

But I don't like idea to create special linux directory just for several files — .AppImage or .snap.

Is this not how the mac directory is though? Correct me if I am wrong, but the .app file is really the only file needed for the unpacked mac application and it is contained in a special mac directory. Maybe the linux-packed directory is a bit of a stretch in my suggested structure and isn't really necessary, but having all of the Linux files in one directory to move around would be useful (to me at least).

BTW, Parallels Desktop allows you to use "Open in Windows" or "Reveal in Windows". And share mac home to Linux if need.

Neat, thanks! I wasn't aware of this as I just recently started developing on Mac recently. I've just been using my MBP and a dual-boot Windows/Linux machine to test the app.

@develar
Copy link
Member

develar commented Aug 18, 2016

a dual-boot Windows/Linux machine to test the app.

Boo. If you don't have money / don't want to buy Parallels Desktop, you can use VirtualBox (but I totally don't recommend it).

@Mercieral
Copy link
Author

Ok to be fair I also have a Fedora image in VirtualBox that I test in but I prefer to use my dual-boot Linux Mint for performance and to make sure everything works both separately and in a VM.

We were required to have the separate Linux boot for a few courses in school as well.

develar added a commit to develar/electron-builder that referenced this issue Aug 26, 2016
@develar
Copy link
Member

develar commented Aug 26, 2016

linux renamed to linux-unpacked. Issue moved to backlog, will be revisited after #529

@develar develar closed this as completed Aug 26, 2016
develar added a commit to develar/electron-builder that referenced this issue Aug 26, 2016
@petoknm
Copy link

petoknm commented Oct 12, 2018

Was this implemented? It still seems that the dist directory is a mess...

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

3 participants