ARM Cortex-M Microcontroller startup files

[Jens Bauer via Digitalmars-d]

On Saturday, 2 May 2015 at 10:38:51 UTC, Timo Sintonen wrote:
> On Saturday, 2 May 2015 at 09:09:44 UTC, Martin Nowak wrote:
>> On Saturday, 2 May 2015 at 08:46:56 UTC, Timo Sintonen wrote:
>>
>> No need to rewrite libc, just link against it and use whatever 
>> is needed.
>>
> I have assumed we are going the way that libc is not a 
> requirement. If libc is required we must build a full multilib 
> set and possibly include them in binary releases.
> This is a question that we can discuss.

Personally, I'd like my distribution package to be the 'full 
package', which provides:
C, C++ and D.
The reason for providing C and C++, is that most vendors write 
their driver libraries in C, and I do not think they're going to 
rewrite their entire driver library, because there's a new 
language in town. ;)
Perhaps some vendors would provide additional D compatible files, 
but it's little likely that they would write a library in D 
without autogenerating it using a script; even that is little 
likely.
Anoher reason is 'the transition phase'. Many users already know 
C, and will be doing certain things in C, until they've learned 
D. They also have sources they've already written, which they 
might want to use, in order to get up and running quickly.

>>> It is a matter of taste if it is a c like printf function or 
>>> a formatter class. Or both if we like. Only the used ones are 
>>> picked from the library.
>>
>> You could implement more high level application code like a 
>> formatting library as dub package.
>
> A separate package is a good idea for advanced things.

I think it's good to split it up. Also development-wise.
Think of it like we need to take small steps as well; we can't 
start testing printf support, before we can build a minimum 
binary for instance.