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

Several changes to help with adding 64bit support. #117

Merged
merged 1 commit into from
Dec 12, 2014
Merged

Several changes to help with adding 64bit support. #117

merged 1 commit into from
Dec 12, 2014

Conversation

theiawolfe
Copy link
Contributor

  • Change osx to osx32
  • Change win to win32
  • Change defaults from ['osx', 'win'] to ['osx32', 'osx64', 'win32', 'win64']
  • Tried to hit some checks I missed.
  • Change osx.json to osx32.json and win.json to win32.json
  • Got failing tests down to 5....

I'm not really familiar with node unit testing, so I'm unsure how to
handle the rest of these failures.

return 'win';
return 'win32';

case 'win64':
Copy link
Contributor

Choose a reason for hiding this comment

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

There is no win64 platform (see here)... This needs to be changed to

case 'win32':
    return process.arch === 'x64' ? 'win64' : 'win32';

Copy link
Contributor

Choose a reason for hiding this comment

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

@adam-lynch
Copy link
Contributor

Got failing tests down to 5....

If you're running on Windows, they're probably just permissions tests failing, that's ok.

We probably should add tests here though for 64-bit builds because the last PR was passing 100% successfully (on my Mac) & there were clearly a good few things missing.

@steffenmllr
Copy link
Contributor

Nice PR! One thing: what do you guys think about this config:

['osx', 'win'] builds both 32 and 64 bit while:
['osx32', 'win64'] will only build the specific versions

Otherwise we would make a breaking change and all users have to change their config

@theiawolfe
Copy link
Contributor Author

I agree, breaking changes are generally a bad thing and I like @steffenmllr's suggestion.

To implement this, I added a little logic to do a quick check on the passed platforms if they are provided and if it finds 'osx' or 'win' they are removed from the list and replaced with 'osx32', 'osx64', or 'win32', 'win64' respectively.

@adam-lynch
Copy link
Contributor

I think for this to be added, then the platform overrides feature needs to support it too. So that means that adam-lynch/platform-overrides needs to support osx64 & win64 but also that osx & win are shorthand for both 32 & 64-bit like we said here.

@adam-lynch
Copy link
Contributor

Also worth noting is that if win & osx are shorthand for both 32 & 64-bit, then linux should exist too instead of specifying both linux32 & linux64 as we have now

@theiawolfe
Copy link
Contributor Author

@adam-lynch Agree on Linux. That would be best practice.

@adam-lynch
Copy link
Contributor

What's the status of this? I can't remember.

@theiawolfe
Copy link
Contributor Author

I believe it is waiting on adam-lynch/platform-overrides#4 to be merged in and then afaik it's good to go.

@adam-lynch
Copy link
Contributor

Ah shit ok, I'll give it one more proper test (with the actual app I'm working on) tomorrow and merge both then.

@adam-lynch
Copy link
Contributor

Wait, had a quick look at the changes there again... isn't this missing support for passing win, osx and linux? E.g. win expands to win32 and win64 for example, like @steffenmllr suggested earlier in this thread.

@theiawolfe
Copy link
Contributor Author

37c83e0 and 2ef9c67 provides the expansion of win/osx/linux to the 32 and 64bit versions.

@adam-lynch
Copy link
Contributor

Maybe it's just missing from the readme then?

@theiawolfe
Copy link
Contributor Author

That is probably the case. I don't believe I updated the README at all.

case 'win32':
return 'win';
return process.arch === 'x64' ? 'win64' : 'win32';
Copy link
Contributor

Choose a reason for hiding this comment

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

@danthewolfe can you apply the same fix as adam-lynch/platform-overrides@d41555c#diff-66d14bf3d12add1ab55262539d9889e0R14 here? Just for Windows

@adam-lynch
Copy link
Contributor

What I think is left to be done on this:


@danthewolfe are you ok to do the first three?

@adam-lynch
Copy link
Contributor

Just built a 64-bit Windows app 😀

@theiawolfe
Copy link
Contributor Author

Applied the three changes described above.

@theiawolfe
Copy link
Contributor Author

like so?
return (process.arch === 'x64' || process.env.hasOwnProperty('PROCESSOR_ARCHITEW6432')) ? 'win64' : 'win32';

Should that change also be made to osx and linux?

@adam-lynch
Copy link
Contributor

like so?

Yes.

Should that change also be made to osx and linux?

No.

@theiawolfe
Copy link
Contributor Author

👍

@adam-lynch
Copy link
Contributor

Would you mind squashing and rebasing these commits into one commit? I'll merge then and release 1.0.0 or maybe I'll merge #123 (as it is) and then release 1.0.0.

@theiawolfe
Copy link
Contributor Author

Forgot to rebase. Hang on.

@theiawolfe
Copy link
Contributor Author

Squashed and rebased.

@bastimeyer
Copy link
Contributor

Shouldn't the tests be updated as well before merging these changes?
e.g. https://github.com/danthewolfe/node-webkit-builder/blob/febf15b0dc8bec75cba9ed7b7ec10b95deadaaff/test/nwBuilder.js#L108

Also (wrong thread, I know):
@adam-lynch Do you want me to make a quick fix for the async build error I've encountered with my last PR?

@adam-lynch
Copy link
Contributor

@bastimeyer

Shouldn't the tests be updated as well before merging these changes?

Some are but yeah, we missed those. @danthewolfe, I guess that should be:

 t.deepEqual(x._zips.osx32, x._zips.osx64, 'OSX 32-bit ZIP should be equal to the OSX 64-bit one');
 t.deepEqual(x._zips.osx64, x._zips.win32, 'OSX 64-bit ZIP should be equal to the Windows 32-bit one');
t.deepEqual(x._zips.win32, x._zips.win64, 'Windows 32-bit ZIP should be equal to the Windows 64-bit one');
t.deepEqual(x._zips.win64, x._zips.linux32, 'Windows 64-bit ZIP should be equal to the Linux 32-bit one');
t.deepEqual(x._zips.linux32, x._zips.linux64, 'Linux 32-bit ZIP should be equal to the Linux 64-bit one');

@bastimeyer

Do you want me to make a quick fix for the async build error I've encountered with my last PR?

Oh, yes please if you can.

* Change osx to osx32
* Change win to win32
* Change defaults from ['osx', 'win'] to ['osx32', 'osx64', 'win32', 'win64']
* Tried to hit some checks I missed.
* Change osx.json to osx32.json and win.json to win32.json
* Got failing tests down to 5....
* Re-adding support for 'osx' and 'win' to avoid breaking changes
* Check for 'osx' and 'win' in the platforms list and replace them with 'osx32', 'osx64', and 'win32', 'win64' respectively.
* Fix tests.
* Add linux shorthand to compliment win and osx shorthand.
* Add fix for detecting Windows 64-bit.
* Update platform-overrides dependency to ~1.0.0
* Add win, osx, linux and description of what they do to readme.

Add additional tests.
@adam-lynch
Copy link
Contributor

@danthewolfe ah just saw you updated the tests or else @bastimeyer was looking at the wrong branch or something. Merging.

adam-lynch added a commit that referenced this pull request Dec 12, 2014
Several changes to help with adding 64bit support.
@adam-lynch adam-lynch merged commit ed35765 into nwutils:master Dec 12, 2014
@adam-lynch
Copy link
Contributor

Thanks again @danthewolfe and @bastimeyer. I'd appreciate if you could test master (npm i -D mllrsohn/node-webkit-builder) before I release 1.0.0.

@bastimeyer
Copy link
Contributor

@adam-lynch
Copy link
Contributor

@bastimeyer ugh yeah, I was going to get to that. Do you know what needs to be changed? I'm not familiar with it at all.

Hopefully it just needs to be changed to:

      // maintain backward compatibility by supporting old platform style
      switch(opt){
        case 'win':
           if(!!options[opt]) {
            addPlatform(nwOptions, 'win32');
            addPlatform(nwOptions, 'win64');
          }
          break;
        case 'win32':
        case 'win64':
          if(!!options[opt]) {
            addPlatform(nwOptions, opt);
          }
          break;
        case 'osx':
           if(!!options[opt]) {
            addPlatform(nwOptions, 'osx32');
            addPlatform(nwOptions, 'osx64');
          }
          break;
        case 'osx32':
        case 'osx64':
          if(!!options[opt]) {
            addPlatform(nwOptions, opt);
          }
          break;
        case 'linux':
           if(!!options[opt]) {
            addPlatform(nwOptions, 'linux32');
            addPlatform(nwOptions, 'linux64');
          }
          break;
        case 'linux32':
        case 'linux64':
          if(!!options[opt]) {
            addPlatform(nwOptions, opt);
          }
          break;

        case 'mac':
           if(!!options[opt]) {
            addPlatform(nwOptions, 'osx32');
            addPlatform(nwOptions, 'osx64');
          }
          break;

@bastimeyer
Copy link
Contributor

The old config format was { win: true, mac: true } which is now { platforms: ['win','osx'] }
I think it would be just fine to only add the missing values, since the win->{win32,win64}, etc. aliases are already defined here... This should be good:

        case 'win':
        case 'win32':
        case 'win64':
        case 'osx':
        case 'osx32':
        case 'osx64':
        case 'linux':
        case 'linux32':
        case 'linux64':
          if(!!options[opt]) {
            addPlatform(nwOptions, opt);
          }
          break;

        case 'mac':
          if(!!options[opt]) {
            addPlatform(nwOptions, 'osx');
          }
          break;
        case 'mac32':
          if(!!options[opt]) {
            addPlatform(nwOptions, 'osx32');
          }
          break;
        case 'mac64':
          if(!!options[opt]) {
            addPlatform(nwOptions, 'osx64');
          }
          break;

@adam-lynch
Copy link
Contributor

K I'll add this in awhile and see if it's ok.

@adam-lynch
Copy link
Contributor

Ok, done.

@bastimeyer
Copy link
Contributor

Thanks!

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.

4 participants