I discovered a serious problem with latest versions of XDK for Windows and OSX.
In the old versions of XDK it could be possible to force the build of nodejs NPM modules on the Edison board. In this configuration, for example, if I work on a Windows PC and I want to use bleno v. 0.1.4 that it is not compatible with Windows it works fine.
In the latest XDK the compatibility of the OS of a NPM module this done machine used to run XDK, eg. Windows. If it doesn't supported I get a cryptic "unsupported" error. The only case it works fine is if you have XDK on Linux, but it fails on Windows and Mac (eg. bluetooth-hci-socket module on OSX).
Of course you can manually install the module on the Edison.
I'd like to know if the XDK product Team is aware of this problem and when it will be fixed.
Could you please provide us an image of the error that you're getting? Also, do you have any specific example of this happening so that we can reproduce the issue? Aside from bleno that is.
here the bug repro steps on OSX, same behaviour on Windows for an NPM module incompatible with it.
Create a blank project that require an NPM module that it is not supported on OSX, eg. 'bluetooth-hci-socket'. Insert the dependencies section in package.json end the require of the module in the main.js.
When you perform the upload you got following messages in the msg window:
Fetching packages using NPM: Installing bluetooth-hci-socket@latest
npm WARN package.json email@example.com No repository field.
Error installing NPM Module. Unsupported Upload Complete
and you got following msg box:
If you perform a manual install in the Edison (npm install bluetooth-hci-socket) it works well as expected.
I attach the sample project for reference. Please let me know if you need more info.
What options do you get when clicking on "Manage your daemon/IoT device"? Do you get something like this, "Run npm install directly on IoT Device"? Is it enabled? If it isn't, try enabling that option and build your project.
Do you get different results after this?
I'm not getting the "unsupported" error, so maybe it has something to do with the software configuration.
can you please tell me what version of XDK are you using for your test?
As I wrote in my original post:" In the old versions of XDK it could be possible to force the build of nodejs NPM modules on the Edison board."
The feature you mention is gone several months ago, or maybe I cannot find it on the latest 2571 build, in this case please give me the instruction on 2571 to find this setting.
I apologize, I was using an older version of the XDK. I just test the issue with the latest version of the XDK and encounter the same behavior. Let us do some more research to see if there's a way to avoid the issue.
The error I am seeing is this:
> firstname.lastname@example.org install /home/root/.node_app_slot/node_modules/bleno/node_modules/bluetooth-hci-socket
> node-gyp rebuild
gyp WARN install got an error, rolling back install
gyp ERR! configure error
gyp ERR! stack Error: getaddrinfo ENOTFOUND
gyp ERR! stack at errnoException (dns.js:37:11)
gyp ERR! stack at Object.onanswer [as oncomplete] (dns.js:124:16)
gyp ERR! System Linux 3.10.17-poky-edison+
gyp ERR! command "node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/root/.node_app_slot/node_modules/bleno/node_modules/bluetooth-hci-socket
gyp ERR! node -v v0.10.28
gyp ERR! node-gyp -v v0.13.0
gyp ERR! not ok
Is this the error you are getting? I am not surprised that the get failed since my board does not have a path to the internet, but I don't currently understand why it would be trying to get that file either (node 0.10.28 being what is installed on my board)
If not, can you post the error, and also your package.json file, or enough of it to reproduce the error, would be handy. To test this I just banged a "bleno" : "latest" line into a random package,json file.
I also don't understand how the platform dependency arises, and how it is handled, so any advice you can give on that will be useful.
sorry I'm not sure your questions was addressed to me. In this case if you please read all the thread, I already posted a zip file to reproduce the problem and the screen capture with the error messages.
As I already wrote you need to try to install an NPM package that isn't supported by the OS that you XDK is running on. Can you please tell me if you are using Windows or OSX?
Ah - I did not see that reproducer and screen capture when I first looked at this. Clearly what you got was different. I will give that a go.
We do lack a "do the (entire) install on the device" option. Adding such an option may be the best we can do here. However it would mean to use that option you would have to have internet access from your device. So it won't work for everybody. It would be nice to find a better solution.
So I would like to understand what directives cause the download (the npm load step) to vary according to platform? Perhaps there is an option I can set to control the platform. Perhaps I can detect the setting and take avoiding action. At the moment I really don't understand the problem well enough.
Re the error I saw - clearly that is the wrong version of node, but what I don't understand is why it was trying to get node at all.
I'll be happy with "do the (entire) install on the device" option, it worked for at least one year before latest XDK versions.
In the latest XDK versions all npm modules are dowloaded on the PC/Mac, zipped and transferred to the Edison for npm module install. Each module in the dependecies section of package.json file is dowloaded on the PC, and npm check its dependencies and download other modules if needed.
Unfortunately these dependency check is done using the PC/Mac OS environment. If one module it is supported on Linux (Edison) but it isn't on Windows/OSX will arise the problems that I pointed out.
This is what i think it happens. To solve the problem you should be able to force NPM to use Linux as target OS during the module download phase on the PC/Mac. I'm sorry but I don't know if this could be possible.
So I did a bunch of reading and I see that the problem arises when the module wants to run an install script. As we have no control over what is in the script we have no alternative to run it on the board. So making that an option is, in fact, the only solution. In other words, installing that kind of module on a board that can't do a fetch is not viable.
I have put together a possible fix, adding it as an option in the download control, and will run it past the team for approval when they get back after the break.
Thanks for your help in improving the Intel XDK.
There is now a button on the upload control dialog to cause the install to completely happen on the board. Of course, you need to have internet access from the board for this to work.
Just to clarify, now === the upcoming release.
I am actually in the process of making some final cosmetic changes to the dialog box display of the new button as we speak.