41–50 of 71 posts
Earlier quoted context omitted.
I just used the Apache license.
Apache committer here - you’ve got the wrong header there. That one’s for source which has been committed to ASF repos under a CLA. You want the header for non-ASF code which can be found here: http://www.apache.org/licenses/LICENSE-2.0.html#apply
Thanks.
I’m working on a compiler right now that generates C. Should I use this for the generated code? (Or should I use glib, musl, or uclib?) A comparison chart would be helpful! Similar to: http://www.etalabs.net/compare_libcs.html
Now, as a language developer, you actually don't have to worry about any of these. The c standard library will be provided by the os and you don't have to think about it. Some programming languages that want to replace c don't rely on the c standard library, but you shouldn't have to worry about that. As for abstracting out different platform apis, I would say that doesn't really belong in your language itself.
1: https://en.wikipedia.org/wiki/C_standard_library
2: https://developer.gnome.org/glib/
3: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...
Earlier quoted context omitted.
To solve the problem in a robust way, the C library has to be part of the target. For example on Debian Linux, glibc is the native libc. On Alpine Linux, musl is the native libc. In LLVM terminology, this is the "C ABI environment" part of the "target triple". If your compiler supports cross compiling, you might look into the strategies that Zig does[1]. If it only supports native builds, you probably want to detect…
That is the standard library, TBOX is just a third-party library, providing some easy-to-use cross-platform modules.
Earlier quoted context omitted.
That is the standard library, TBOX is just a third-party library, providing some easy-to-use cross-platform modules.
Any plans to do a Libc too? A lot of embedded systems like ESP32 could really use a good Libc without having to pull in Linux.
You can see https://github.com/tboox/tbox/tree/master/src/tbox/libc
Should I then assume that the compatible platforms are actually more than the listed Windows, Linux, Mac, and mobile OSes?
I'm on the front of AVR development, and cool new things always arrive late (understandably, if they arrive at all...) to our little corner of the world :(
But I assume that "embedded" here will mean mainly ARM.
(similarly, I'm still excitedly waiting for more progress on the Rust front :)