search

kauailabs / navxmxp

Robotics Navigation Sensors. NavX-MXP designed for the National Instruments RoboRIO & FIRST FRC Robotics. Navx-MIcro designed for Android-based FIRST FTC Robots
MIT License
105 stars 87 forks source link

Setup program does not work on *nix, along with some terrible practice in general #4

Open yonip opened 8 years ago

yonip commented 8 years ago

Your setup program is exported as a .exe, which is not natively executable on *nix operating systems. However, when I ran the app with WINE, the program tried to use my JVM, which obviously means that the setup program uses compiled java code. Why was this program packaged as a .exe instead of a runable .jar? Additionally, I see nowhere a location for downloading the .jar files themselves, which seems counter-intuitive, since, from your setup tutorial, it appears that all your setup program does is put your libraries in <HomeDirectory>\nav-mxp\ or ~/nav-mxp/. Why not give this freedom to the user by simply supplying the libraries. If you're expecting the users to edit their own build.properties, I'd imagine you can trust them to put files into folders. Also keeping IDE specific files in your repository is terrible practice, even if you assume most people will be using Eclipse.

kauailabs commented 8 years ago

The setup program is generated by Innosetup, which generates an EXE. If the setup program happens to use the JVM internally that's an implementation detail of Innosetup.

Note that the setup program installs far more than just the java libraries, it also installs many executable utilities as well as C++ and Labview libraries as well on a developer's PC. So the overall scope of the work performed by the install may be greater than you realize.

For developers running on non-Windows platforms, making the the libraries separately available (e.g., as standalone files within the zip) is definitely possible - you are the first to request this. Please confirm that this solution would help your situation.

kauailabs commented 8 years ago

The following is some feedback on the following comments: " Why not give this freedom to the user by simply supplying the libraries. If you're expecting the users to edit their own build.properties, I'd imagine you can trust them to put files into folders. Also keeping IDE specific files in your repository is terrible practice, even if you assume most people will be using Eclipse." The sad situation of having to edit build.properties files is forced upon us by the limitations imposed by the structure of the Java WPI-plugin-generated project files. An enhancement request has been submitted to WPI on this topic, and we are hopeful that an upcoming release of the WPI library will more gracefully support 3rd party libraries than currently, at which point the need to edit the build properties files should be removed. WIth a Java FRC program, the build process must not only link to the libraries, but also package them for download to the RoboRio which likely accounts for the complexity, in addition to some ant-related limitations.

As to the IDE specific files, our goal is to be able to install complete sample programs into "example" directories on the developer's machine (these are installed by the setup program). So this could account for at least some of the IDE specific files in the repository. Once the setup runs, the user can quickly import the sample projects and get up and running. However, if there are particular files (not strictly necessary for the purposes of example projects on a developer machine) which you think should be removed, kindly indicate specifically which files and we will definitely review that.

yonip commented 8 years ago

Thank for the prompt response to my, rather argumentative, comment. I definitely did not realize that the .exe was for more than just the java libraries, an assumption I made based off of the fact that I got it from the java install page. Having the libraries provided in the .zip, with perhaps a small explanation as to their relation to the "installation instructions" on your website would definitely be very helpful. If the C++ and LabView libraries can be added to the build path in the same manner any java library can, I'd imagine that having those libraries in the .zip would also be helpful to any that use those languages. Would it be possible for your team to create setup scripts for *nix as well as windows? And perhaps a clear separation between installers/setup scripts for each language? (i.e. instead of just setup.exe you can have setup-java.exe, setup-cpp.exe etc.) I'm surprised no one asked for this before.

TL;DR yes please having the libraries separately available would be great, thanks for responding

kauailabs commented 8 years ago

A new .zip file which contains only the navX-MXP libraries for FRC/FTC is now available, as described on the navX-MXP software page. See the readme.txt file in the root of the zip file for installation instructions, including a brief description of the differences between installation on Windows and on a Linux platform, which you can use to allow using the documented Java library getting started steps.

Please give this a try and let us know the feedback. If you end up coming up w/a install script that accomplishes the manual installation instructions described in the readme.txt, send that to us and we will look into including it in the non-windows build zip file. We don't have a good way to test it, so your feedback here is appreciated.