Hi, On 01/02/15 07:07, Paul Fertser wrote: > Hello, > > Here I will express my own personal opinion, which is not an official > position of the OpenOCD project. I hope the maintainers will state > their opinions in separate mails. >
I am not an OpenOCD developer (I would very much like to get involved in it, but I haven't yet found the time), and only a relatively light user of OpenOCD as yet - for complicated reasons, most of my ARM debugging is currently done from a Windows machine with a P&E Micro debugger. However, I'd like to offer my opinion here if I may, as an alternative viewpoint. For background, I use both Windows and Linux systems for development, with my colleagues using mostly Windows. The great majority of my work is programming small embedded systems, but I occasionally do development on PC's. Although I do very little C programming on PC's (Linux or Windows), I have no problem compiling existing projects if required. However, I also know how "normal" embedded developers work. > I consider GNU ARM Eclipse Plug-ins to be a very useful and essential > part of an embedded developer toolbox. But this announcement made me > feel uneasy about your OpenOCD packaging efforts, please see inline > why. For the majority of embedded developers, pre-built binaries are an essential requirement. There are several reasons for this: Like it or not, most embedded developers work under Windows. Windows does not have any development tools as standard, and most embedded developers do not have a native compiler on hand. For those that do, there is no standard - tools range from various versions of MSVC, gcc (from cygwin, mingw, or mingw64), Borland C++ builder, and many "odd" compilers. It is impractical or impossible to support or test all these different tools. Many embedded developers are not free to choose or install different compilers or tools on their windows workstations. Even for those that have a native compiler or are using Linux, there can be requirements for using pre-built versions (since someone else has responsibility for the build process, and it removes a possible source of error. Even for projects with an explicit "no guarantee" clause, a pre-built binary is likely to have more testing than a locally built version). As to where to get the tools, it is often an advantage to the user to be able to get related tools from the same place - such as getting the OpenOCD binaries from the ARM Eclipse plugin website. It is also fine to have links to binaries from another site, but having the connection here means that everything is easier to find, and gives confidence that the different parts will play together. For example, the OpenOCD developers may make a change that causes an incompatibility with Eclipse - the binaries from the Eclipse plugin site should stick to the old versions until the issue is resolved, while binaries from other sites might have moved to newer OpenOCD versions. Whether such confidence is well-founded, and whether the new binaries are well enough maintained for this is another matter, of course - and not something I can comment on. > > On Sun, Feb 01, 2015 at 06:04:43AM +0200, Liviu Ionescu wrote: >> Since I saw the recent discussion regarding the difficulties of >> building OpenOCD on Windows, please note that I recently added a >> binary distribution of OpenOCD to the GNU ARM Eclipse plug-ins >> project (http://gnuarmeclipse.livius.net/blog/openocd/). > > How a binary distribution helps end-users to build OpenOCD? It helps them avoid building OpenOCD (especially on Windows). > >> The big novelty is that it includes two setup wizards for Windows >> (32/64-bit) and one installer for OS X. > > MSYS2 already provides binary packages for OpenOCD, and a very easy > way to rebuild from the sources, when needed. > > Homebrew already provides both latest release and git HEAD in a > trivially accessible way. If there are good enough binaries available elsewhere, then there is no need to duplicate the effort - that would be a waste. It would be better to have links or copies rather than new builds. > >> Although less important since most Linux distros already include >> OpenOCD packages, this new distribution also includes two archives >> for GNU/Linux (32/64-bit) that have the advantage of being packed as >> standalone folders, that can be installed anywhere without having to >> explicitly specify the path to the scripts folder. > > I do not like an idea to provoke the users to circumvent their distro > packaging system. I, on the other hand, /do/ want to circumvent my distro's packaging system for my embedded development tools. Debugging tools are less critical than compilers and libraries, but I want to have the same version of openocd on my old Fedora 14 system, my newer Mint 17 system, my Windows system, and any other machines I use. And when there is a significant new version of OpenOCD out, I want to install that /alongside/ the existing version - not as an "apt-get update" replacement. The last place I would look for embedded development tools would be my distro's repositories, because I value consistency and repeatability above "latest and greatest" for such development. I need to know that in ten years time, everything will work exactly as it works now - I don't want to find that a ten-year newer version of the software has removed support for my old hardware. (Having the source code in archives is an important part of achieving this, but binaries are involved too.) > > I would prefer to consolidate all the userbase instead of making it > more diverse by yet another binary build. Also, I would prefer to have > every end-user capable of rebuilding OpenOCD from the sources with > trivial effort. It is always good to avoid duplicating effort, and no one ever complains when a program is easier to rebuild from sources. But pre-built binaries is the medium of choice for most embedded developers. > > Hence I was working directly with distro maintainers to ensure their > users can get openocd running and building by distro-recommended > way. In the OS X case, I consider Homebrew to be the distro (I know > about Macports and Fink, yes, and I hope their users will manage to > maintain the openocd package themselves if they need it); in the > windows case I consider MSYS2 to be the distro. > > Installing binary packages outside of the repository is something I > would not recommend to anybody. > Here, as I said above, I disagree. For a program like OpenOCD it is not a big issue - and having it in distro repositories is convenient, especially for "light" users. But if I take a version of OpenOCD as a basis for a test or production programming procedure, it will be a specific version - /not/ a version from a repository, or the latest Git version. So while I think it is great that you work with the distro maintainers to make it convenient to get the latest builds, it is also important to work with archived source and binary builds outside of the repositories. Best regards, David ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
