You are not logged in.
Greetings,
I am not sure the size of my target audience and consequently this message may be lost in the crowd. I maintain the msp430-elf toolchain in the AUR and this message is mainly targeted to the users of the toolchain, although those with an opinion/experienced in the matter are welcomed to weight in.
Recently, two patches made it upstream to both gcc [1] and binutils [2] adding a few new microcontrollers to the list of supported devices. The microcontrollers added this time around are a few FRAM based models. The situation here is that the microcontroller list is hardcoded into the toolchain. As such, adding new microcontrollers to the list requires patching the sources and rebuilding the toolchain. For casual users of the toolchain, I believe this is not an appealing choice, even when AUR wrappers are used to automate the process. With that being said, I also do not like patching upstream sources unless it is to fix a bug that detracts from using the toolchain [most recent example is the patch in the binutils package to fix the dwarf2 address size, which was causing issues with gdb]. I did have to patch binutils once already to add new microcontrollers when I updated the gcc package to version 5.3.0 [gcc released first].
I should note that the old mspgcc toolchain did not have this problem, as the list of microcontrollers was kept as a separate package [3]. Peter Bigot, the maintainer of the mspgcc toolchain, called this a bad design and filed a bug upstream, but so far, it has not been resolved in a satisfactory manner [4,5].
My question here is: should I upload new package builds with the patches, or should I wait until the next minor version? Please consider that adding these microcontrollers to the list imply that users need to rebuild portions of the toolchain. Thank you.
Cheers,
Orlando.
[1] https://gcc.gnu.org/ml/gcc-patches/2016 … 01145.html
[2] https://sourceware.org/ml/binutils/2016 … 00243.html
[3] https://www.mail-archive.com/mspgcc-use … 12200.html
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63953
[5] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901
Offline
EDIT: nevermind, you are already packaging it from upstream gcc. I didn't look at the right package, closely enough. Mia culpa.
Last edited by alexei (2016-03-24 17:31:57)
Offline
EDIT: nevermind, you are already packaging it from upstream gcc. I didn't look at the right package, closely enough. Mia culpa.
Greetings,
Thank you for your reply. Although now edited, I managed to read it before it was changed [no need to apologize, by the way].
You do raise a very good point though: users who want the patch would likely be aware of the patch's existance and are very likely to know how to apply it themselves. For the time being, I will leave upstream patches alone and update as new releases come about [unless bugs are encountered in the current versions of the packages]. From reading the mailing lists and bug reports on this way of handling new microcontrollers, the list seems to be used internally by the compiler to determine the capabilities of the microcontroller [hardware multiplier type, memory model and the likes], which have discrete flags that can be used to finetune the options [preprocessor symbol generation and linker script selection will happen regardless]. This does place an extra burden on the user, but seems like a fair compromise.
Again, thank you.
Cheers,
Orlando.
Offline