On Tue, 21 Nov 2017 17:35:04 -0700 Warren Young <war...@etr-usa.com> wrote:
> A great many embedded projects use Keil and IAR C, for example. As > far as I’m aware, Keil doesn’t do C11 yet, and IAR didn’t get support > for it until earlier this year. > > It’s quite common in the embedded space to buy a version of the > commercial compiler, let the one-year maintenance period expire, and > keep using the old version rather than pay yearly maintenance. I’ve > heard of embedded projects where the compiler is checked into the VCS > alongside the source, since they intend to never upgrade it. Yes, I'm aware of that - I've been in the embedded system business for a long time. In fact, if you use a commercial compiler, you'd better save it, and the OS that can run it, and hardware to run the OS (or a suitable emulator) for there's no guarantee that the compiler vendor or any other part of the build chain will be around in 2, 5, 10, 20 years time. Ever used Introl compilers? Or Lattice (later SAS)? But what I'm saying is that if you archive your compiler for the project, then you can (and should) also archive whatever other 3rd party software you use, for example SQLite. Even if you use open source tools that's the case. There are embedded systems out there that can't be compiled with gcc more modern than 2.95 (i.e. pre-EGCS). But that hasn't stopped gcc to evolve. The fact that there are devices that were built with SQLite 1.0 using WhizzBangC+- 0.01alpha 15+ years ago shouldn't hinder SQLite 3.x or 4.x and it could safely step forward from C89 to C99. That standard is over 15 years old and most commercial compilers has supported it for years. Nevertheless, this has very little to do with the actual issue of git/CVS/mercurial/whatever support in Fossil, so I shut up. Regards, Zoltan _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
