On Wed, 10 Dec 2003 10:03:35 -0800, Bruce Korb wrote: > This is plain nutty. Indeed. Portability issues almost always are. At any rate, I was not suggesting that that approach be used, but rather was pointing out potential problems in the proposal, along with some possible solutions. I am all in favor of simpler and cleaner solutions, and it seems that we have finally arrived at one. > What is terribly wrong with requiring a minimalist install environment > pre-installed? You know, autoconf checks for it and if it has not been > installed and echo and grep don't work, then just choke and die. But how does one define a "minimalist" environment, and if one person's idea of minimal makes numerous assumptions which are not exactly minimal, then how would truly minimal environments be configured in the first place? There has to be some way to bootstrap the environment, and to do so means utilizing the tools which are already available on that platform, such as Bourne shell, make, etc. It is precisely tools, such as Autoconf, m4, gcc, and whatnot, which cater to the bootstrapping process, thus it makes sense to put extra effort into these tools to ensure that they are able to fulfill that role. It is not necessary to spend an enormous amount of time pandering to portability for every single project, but it is useful to do so for the few tools which make bootstrapping possible. > How many programmer hours are squandered hassling over silly > things that were fixed 20 years ago? Many of the issues that Autoconf handles are not 20 years old; plenty are much more recent than that. At any rate, the goal of Autoconf is to insulate developers from these portability issues as much as possible. It is precisely this insulation which frees the majority of programmers from having to waste their time over portability concerns. If one person can spend a few hours enhancing Autoconf, then everyone else benefits without having to waste any of their own time. Thus, "programmer hours" have been gained, not wasted. > At what point are hobbiest platforms dropped so > that programmers can presume target platforms that are less than a decade > old? Sheesh! What a waste of time. It is not just a matter of hobbyist platforms. There are plenty of businesses using technology more than a decade old, which can not simply ditch their legacy platforms in favor of newer technology. In a large corporate environment it can take a long, long time to migrate to newer technology, so being able to build and utilize modern tools on these older platforms is can be very important. Programmers and users can benefit greatly from modern tools even if they are constrained to working on legacy platforms, and would likely not consider the effort put into Autoconf to be a waste of time. One of my jobs was working as part of a small team to replace antiquated mainframe software (for a hospital system), which itself was 15 or 20 years old. We chose modern hardware and modern technology (NextStep 2.1 - 3.3) and produced a very high-tech system which is still in use today. But, guess what? At 12 or 14 years old, that system is also now a legacy system probably quite in need of replacement, yet it is still up and running all these years later. Corporate migration tends to go very slowly. It is not just a matter of dropping in new hardware and popping in some new software, but instead often involves creation of entire new systems and infrastructures, so tools such as Autoconf, and projects which care about portability and legacy systems, are important and welcome. -- ES
