dwrobel wrote:On the other hand I was able to just compile and boot succesfully the embox project on my NXT. This project uses the arm-none-eabi-gcc toolchain which currently seems to be preffered toolchain from distribution's point of view. In other words having possibility to use this toolchain would significantly help maintaining lejos package. Please consider to support it.
dwrobel wrote:Now the pacakge is almost ready. It allows either to reuse the binary NXT firmware blob without recompilation or recompile it using either the arm-elf-gcc or the arm-none-eabi-gcc toolchain with the information that the build compiled with the arm-none-eabi-gcc toolchain is currently not supported.
gloomyandy wrote:* Is the source used for the fedora release pulled directly from the leJOS CVS repo or is there some sort of manual upload of the source?
gloomyandy wrote:* What happens if the leJOS repos are updated? Who/what will update the fedora release and when will this update happen?
gloomyandy wrote:*As to the toolchain issues, if you are offering to port the source to a new tool chain and support that new port then please talk to us.
I'm planing to preprare an RPM package of NXT software to have fully reproducible and stable build system.
Basically I've managed to compile the latest stable version from the svn tag lejos_nxj_0.9.1-3 (as the official sources doesn't contain eclipse plugin sources) and it works quite well (tools, examples, eclipse plugin).
A few comments/thoughts on all of this....
Unless there is someone prepared to test and support a new build of the firmware then I do not think it is a good idea to make anything other than the standard leJOS firmware image available to users. This includes any build from source that results in a binary this is not identical to the standard leJOS image.
gloomyandy wrote:Which is all very well but none of that applies to the leJOS firmware (which was the subject of the text you quoted).
gloomyandy wrote:I am also not very comfortable with having someone that has not had a long term involvement with leJOS being responsible for creating a new distribution.
gloomyandy wrote:So we need to do one of the following:
* Ship a binary version of the firmware and have people use that (my understanding is that this may not be acceptable for some distributions)
* Ensure that the binary built from the firmware source is identical (my understanding is that this will not be the case because different versions of the gcc cross compiler will be used with different distros).
* we need someone who will handle any problems that users may experience.
gloomyandy wrote:Is using the binary blob the default option?
gloomyandy wrote:I've looked at the spec file, but it is not really possible to verify that this will result in a standard build just from inspection of the file, and I don't have the time to setup a build system to try all of this.
gloomyandy wrote:So is the resultant binary file identical to the one we currently ship (other than date/time stamps)? If not then ideally you need to understand why not as this may indicate some problem with the build process.
$ svn checkout svn://svn.code.sf.net/p/lejos/code/tags/lejos_nxj_0.9.1-3
$ svn info
Working Copy Root Path: /home/dw/projects/lego/nxt/lejos-nxj
Relative URL: ^/tags/lejos_nxj_0.9.1-3
Repository Root: svn://svn.code.sf.net/p/lejos/code
Repository UUID: 06c8f799-c779-4783-8af7-179afedb67c8
Node Kind: directory
Last Changed Author: skoehler
Last Changed Rev: 6624
Last Changed Date: 2012-05-29 22:13:18 +0200 (Tue, 29 May 2012)
$ svn log | head -n 4
r6624 | skoehler | 2012-05-29 22:13:18 +0200 (Tue, 29 May 2012) | 2 lines
gloomyandy wrote:Perhaps changing this to add some offset to the minor version would be best (so for instance rather then build 0.9.1 you would use 0.9.101 or some such scheme). The version number is held as a hex number and is passed into the gcc command line.
Users browsing this forum: Yahoo [Bot] and 1 guest