Re: [Mingw-msys] RE: Differences between mingw-make and msys' make

[Soren A]

Earnie Boyd <address@hidden> wrote around 24 Sep 2002
news:address@hidden: 

> 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