Short Guide on Compiling NewRPL

[Han]

Thank you for the info on the errors and memory.h

(11-18-2016 04:57 AM)Claudio L. Wrote:  

(11-18-2016 03:12 AM)Han Wrote:  Updated to include Mac OS X instructions. I compiled the firmware, but have not tested the firmware file (left my 49G+ and 50G at the office). Claudio, can you comment on the errors mentioned at the end of the Mac OS X section in the first post?

I can tell you that I compiled both UI and FW on Ubuntu (64-bits) and on FreeBSD (32 and 64 bits) (most similar OS to a Mac that I can get) and it compiled with zero errors. I also compile UI on Windows (32-bits) and get zero errors. Sometimes I get a spurious warning about a comparison on ui_cmdline.c that makes no sense to me.

On Mac, there are numerous warnings about instances were const is used twice in a declaration (e.g. const unsigned int const <blah>) but this is likely just due to Xcode being extremely picky. Once I got the projects to compile, though, I no longer saw them in the logs so I cannot give any further details. (Even using make clean and rebuilding did not show any warnings after the minor modifications I had mentioned.)

(11-18-2016 04:57 AM)Claudio L. Wrote:  Regarding memory.h: It was an old #include needed back in the early days, but I eventually replaced all calls to memcpy and friends with my own memcpyw and memcpyb to become completely independent from any system library, so memory.h became obsolete and can be removed with no consequences (I'll commit that change tomorrow). It's a standard header, though, it should be there even on Mac. Perhaps there's some missing basic headers?

It's there, but I think runstream.c was looking for it within the mpdecimal library. At least the newRPL-BASE.pro file seems to suggest so, anyway. But I am glad to read that removing it is OK.

(11-18-2016 04:57 AM)Claudio L. Wrote:  Also the problem with types should never happen: The first thing newrpl.h does is define all those custom types: WORD is defined as uint32_t to be 100% consistent across multiple platforms. Replacing WORD with unsigned int is superfluous, as they are the same type, same as replacing int with BINT in your example. I'm not sure where those errors come from.

I was surprised by this as well. I think the Mac compiler is just super picky. At any rate, the differences were:

• battery.c vs hal_api.h: battery.c uses unsigned int __battery __SYSTEM_GLOBAL__; and at the same time includes ui.h (which then includes hal_api.h). Within hal_api.h is the declaration WORD __battery; which makes the Xcode compiler upset
• decimal.h declares BINT sig_digits(BINT word); but decimal.c defines the function using int sig_digits(BINT word). So it seems that Xcode just likes to be very particular about types (despite the typedef in newrpl.h)
  

If you already tried compiling the firmware on Windows with no success, then I probably won't bother trying too hard (I too ran into path issues despite using the "DOS" paths that I had to manually determine using dir /X). The only thing I have not tried is to install the compiler in a simple directory at the root of the drive.