I think this question is especially for Lars, but there are probably many of us with an interest in the topic, not least those from outside the Linux environment.
There is always a tension in programming between taking advantage of new features of languages and tools, and maintaining backwards compatibility for commercial OSes which may have a lifetime of up to a decade (more?). There is also the issue of flavours of particular tools (e.g GNU/make vs. vendor-make; gcc vs. vendor-cc; sh/bash/ksh; ...) Both Linux and our Linux-HA/heartbeat/etc. project tend towards the rapid evolution end of the spectrum. Because my own day-job applications of Linux-HA have always had a strong elements of Solaris and of general portability, I have tended to the other, longer-term end of that spectrum. And I know that two of my patches earlier this year, which were to try to get heartbeat to compile under a non-gcc compiler (not for me, but for another Solaris user), were (I acknowledge) probably a step too far for our projects. And Lars rightly advised against them. So, basically, I think it would be useful if we could refresh and revise our internal coding guidelines: what's in and what's out. This is probably a good time, now that the split between pacemaker and heartbeat has become reasonably stable; now that heartbeat is under new management; now that we are looking at openais as an alternative to heartbeat. To set the ball rolling, I suggest something like: o While these projects are chiefly focussed on Linux, we try to make reasonable efforts for them to work on other major OSes, both commercial (Solaris, HPUX, etc.) and free (*BSD). o Overall try to follow GNU Coding Standards where reasonably possible. Put another way, if our code deviates from GCS then we should be able to provide a decent rationale. o Require 'gcc'. (For example, my attempt earlier this year to get a clean compile from Sun's compiler was a step too far.) o What minimum of version of 'gcc'? For instance, Solaris has 3.4.x readily available via the CSW respository. Other OSes might have other constraints: anyone know of any? o Require Gnu/make. It would be nice to allow vendor-make, but there is so much variability, and, given our need to have additional software anyway (e.g. gcc, libnet, ...), saying GNU/make seems straightforward. o Installation locations. GNU tends to default to "/usr/local/bin" (and equivalent locations). We (rightly) need to install in the native-OS locations. (That's the rationale for the coding currently inside "ConfigureMe" and some of "configure".) o Scripts (e.g. RAs) ought to be in commonly available languages, shells, etc. Any "#!/bin/xxx" must be accurate. In other words a "#/bin/sh" must not contain Bash-isms, but a "#!/bin/bash" may make full use of 'bash' features. Libraries of 'sh' functions ought to be available to any sh-like variant, and so should be kept Bourne-compliant. How does that sound for starters? -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
