From: Soren A <sor...@fa...> - 2002-09-25 04:24:06
|
Earnie Boyd <ear...@ya...> wrote around 24 Sep 2002 news:3D9...@ya...: > So, the real problem for this is Soren, or something else? In a bad mood tonight, Earnie? This, what I have been posting, is very useful information for somebody who is actually trying to collboratively work on porting issues with GNU make. It's the guts, the details, the substance. If you are tired or not interested right now, you really don't have to answer. But whatever you do, PLEASE do not turn into cgf and start senselessly, thoughtlessly, carelessly discouraging people are just doing exactly what "hard volunteer work" means. If you don't like something about the style, that's fine but that's just you. John Cronin posted detailed patches and reports about how far he had gotten. I spent 10+ hours re-creating his setup painstakingly and then began testing. I ran into problems right away. I believe this process is called "beta testing" and "debugging." Where I am at right now is that I have got John's changes "hardened" (robustified), based on that real work and not on dogma or commmentary offered while sitting far overhead with a pair of binoculars and a cocktail in the other hand while I am really only mostly watching a ballgame on TV. I know my articles are weird to look at because as far as I can tell, this nearly never happens with MinGW or Cygwin or anywhere else. Face it. The hackers who comprise Us are largely a lot of wanna-be alpha dogs who, once we smell that another dog has pissed extensively over some turf, lose interest (because we want to stake out fresh ground of our own). I for one know that this is a rather counter-productive (if not outright stupid) aspect of human nature that gets in the way of getting the highest-quality results. I more or less *beg* people on OSS Lists to review my work and give me feedback *based on actually downloading a patch and running a build* (not on a quick look-over which results in wasted bandwidth and misunderstandings multiplied). I almost never get that no matter how emphatically I ask. I can live with that -- it just means my results will be more fragile and slower to complete. I "get it" that programmers are highly egotistical about their work and want it to be as individual, creative, singular and unshared with others as possible. We get most stoked about the project which we ourselves as individuals create single-handed from start to finish, so that it has only our own name on it. That's the underlying factor that sets our prioritization (that, and maybe "how many people are howling complaints about a certain bug" in a project we've already released). I believe in putting out what I want to be getting back. In recognition of John's making the efforts he did, I wanted to respond with the most detailed and substantial feedback I could. It only makes sense to do so on-List because that way someone else (a third person) may get in on the game too. When the guys a few years ago announced to the world that they had achieved "Cold Fusion", what happened was that people with no commitment to rigorous scientific rationality (for example: journalists) got all exercized over it. Then eventually teams got set up to try and reproduce their results. We all know how that turned out. What i've been doing with John's contributed patch was nothing other than this, in essence: methodically try to reproduce his results and then try to expand the description of what parameters may impact on being able to do so, for others to come in the future. Debugging. Engineering -- as in "software engineering" -- is an applied scientific discipline. It is not distinctinctly different from science in method, only in goals (the goal of 'pure' science being to further human theoretical knowledge about some aspec tof the Universe, while the goal of engineering is to build something concrete that does something useful). I am not the least bit concerned about revealing my stupid mistakes, lack of knowledge or misconceptions about something "in public" because this is real trial-and-error learning. Others who may not be as expert as you (or as me) can see what I am doing step by painful step and learn about the process from that. Those who may be interested in helping to achieve the stated goal (of merging in all needed changes to get a robust MinGW 'make' buildable without kludges from mainline GNU 'make' source in the future) can extract from the detailed reports a more accurate picture of what issues remain to be resolved, in case (as is very likely with all human beings as opposed to automata [but only when their programming is utterly free of bugs, which is seldom or never]) I err in how I document, explain or describe something. What I *am* absolutely confident about is my powers of concentration and my determination. There are lots of bright people around. Lots of them don't follow through on things a lot. You'll see the kind I mean all over, and not just in OSS communities. They are all too ready to open up their mouths and talk down somebody elses' work or ideas based on fabulously detailed theoretical understanding of many fields of human knowledge. But when it comes to producing something (besides hot air) of actually *use* or *value* to others, they mysteriously disappear. Such people cannot close the gap between talk and concrete result because they lack something that isn't about "intelligence" at all but about that almost extinct concept called "human character". I think the quality of "robustness" in software is a reflection of the person or people who developed it. I think when it's fragile, when it breaks very easily if everything isn't set up just-so, that's a reflection of the person who wrote it: they just didn't have the stamina, determination, concentration or gumption to stick with the tiresome, tedious task of endlessly (it feels like) checking and re-checking the work. I have a setup that is less than perfect and that's a GOOD thing because it means that when a development project lands on MY hard drive, it's in for some real-world (as opposed to theoretical fairyland) banging-about. I am working on Win98 tonight, not even WindowsNT, for instance. I'll post a url for the 'configure.in' file now that I am pretty satisfied with it as far as addressing all the issues that I turned up. http://home.att.net/~perlspinr/build_platforms/mingw- make/configure_in.html And the Makefile.am to go with it is at http://home.att.net/~perlspinr/build_platforms/mingw- make/Makefile_am.html Later on I will post a url for a diff. I already posted previously in refutation of the view that 'working on build configuration files isn't "real contribution".' I will repeat it in somewhat less detail and tact now: Hacking autotool'ed build configuration files *isn't trivial* and anyone who claims it is and on that basis, disses the efforts of another, is about 1/2 as smart as they think they are (and may want us to think they are). Best Regards, Soren A |