As Benjamin Henrion wrote: > Sure, but that does not mean because it is a minority that it should > not go in.
I did not say so, but it's reducing its priority, compared to things that are important for every AVRDUDE user. If you look in the patch trackers, there are many things around waiting for integration, but our (i.e., the maintainers') time is finite, so we have to prioritize, at least mentally. > I will write a blog post on how it works for me. A blog post is *not* documentation to me. (It might be useful in addition to regular documentation, no question.) I need at least one of the two documentation files (avrdude.1, and docs/avrdude.texi) patched, preferrably both. Both could use the same wording, of course, and if someone cannot test one of them due to the lack of tools (like the texinfo suite), the patch could be made "blindly", just indicate this in the patch description. > Right now I have a gentoo ebuild + patch-for-gpio file, it works. I never indicated any doubts about its functionality. > > Would someone be willing to add documentation for it? My main goal > > for AVRDUDE 6.0 is to fix all of the outstanding Xmega issues, and all > > my available resources are tied up with this. > Yes, the gpio enabling requires some commands to enable them, but > that's 4 shell commands to expose the GPIOs in /sys/class/gpio. I cannot see the relation between your statement, and the text you quoted from me. I wrote that my time until AVRDUDE 6.0 is tied up with fixing various Xmega stuff (I've been shoving in front of me for too long already), so I don't have free cycles to write the documentation patch myself. You are replying something about shell commands ... > > Besides, I wonder whether the --enable-gpio feature would better be > > auto-probed in configure.ac? > > Sure, if you do not want to activate that feature in your build, that > should not go in. Still, having the code in on a system that could otherwise support the feature at all (*) would not hurt those who don't want to use it. Am I missing something? It's common practice for AVRDUDE to include all programmer handling code that would *potentially* be applicable for a particular target system, without requiring the user to include or exclude each of them by configure options (as, e.g. OpenOCD is doing). (*) I'm not knowledgable enough about *which* Linux systems are candidates for it. Every Linux with a recent enough kernel? (Which one?) Every Linux that has /sys/class/gpio around? Something else? IMHO, the autoconf.ac stuff could just determine, based on something like those symptoms I mentioned, whether the respective system supports the feature or not, and then enable it. If it's not enabled by default on systems that *could* potentially use it, each user who actually wants it were forced to compile their own, customized binary, because maintstream distribution maintainers will regularly miss to add this option to their configuration scripts. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list avrdude-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avrdude-dev
