Re: MinGW GLib

[Soren A]

Lots of points to cover. I am not going to give equal coverage to all in 
this single reply...

Tor Lillqvist <address@hidden> wrote around 27 Sep 2002
news:address@hidden: 

> Soren A writes:
> > -AC_INIT(glib/glib.h)
> > +## HELLO! new syntax: AC_INIT(PACKAGE, VERSION, BUG-REPORT-ADDRESS)
> > +AC_INIT(glib,2.0.6,['http://bugzilla.gnome.org'])
> > +
> > +AC_CONFIG_SRCDIR(glib/glib.h)
> 
> Are you sure that this works with autoconf 2.13 which is the minimum
> requirement (see the HACKING file)? Anyway, please file a bug report
> on bugzilla.gnome.org, so that the main GLib maintainers see it and it
> won't be forgotten.

I am quite sure it doesn't. And pretty sure it shouldn't; if Glib has a
policy that it has to be backward-compatible to those old Autotools,
then they have issues which I won't get involved with. The Autotools
(autoconf) upgrade discussion is far larger than the concerns of this
forum and has been gone round and round many times. Google'ing (Groups)
would be informational for those who don't have any historical
perspective on what I mean by the dimension of this issue. In any case: 

 # require autoconf 2.52
 AC_PREREQ(2.52

I didn't insert this. The 'configure.ac' in the Glib package has this,
check for yourself. If what's in that file and what HACKING says are at
variance then again there are issues with the maintainership of the
package that are beyond my concerns or reach. 

> > +# This has to be up here, -fnative-struct will break basic tests on
> > gcc 3 +# otherwise and user will not have a clue.
> 
> Well, "user" is a bit misleading for people who even try to build for
> Win32. They usually are rather cluefull, and presumably can figure out
> the -fnative-struct vs -mms-bitfield issue quite well, like you did.

I think you presume that based on insufficient specific knowledge and 
experience to come to a correct sense of the character of the issue.

I'll explain very much at length (basically the rest of my messgae will
be about this). This is a prime example of a woeful shortcoming of GNU
autoconf; it is in a generic and large category of failures which don't
get reported to the user in a way which would be characterized as
"friendly" or "informative" or "helpful" and which in fact do not even
conform to reasonable minimal expectations for professional-quality
software. 

The 'configure' run will simply die from a "cannot run C compiler" error
early on. This is unbelievably unfriendly to novice users of
Autoconf-based 'configure'. Somewhere there is this incredible
disconnect in which people like yourself say "users of XXX don't know
about lib/ or DLLs" but then expect someone who would be willing to try
running a 'configure' script to be an all-out Guru with nearly
supernatural powers of diagnostic insight. I have news for you. Many
people who will run a 'configure' script will not even know to go `vim
config.log' until they've struggled for quite a long time and their
frustration level has reached redline. I report this as my own
experience -- my life-experience in the sense of going back however many
years since beginning to build software from source code. Experts ignore
or dismiss this kind of data point at peril of being completely, truly
disconnected from the reality of what the users they are supposedly
'server' have experienced. If it's just me saying this, then how many
other people who you will never hear from (because it doesn't seem worth
it to them to make the effort, because they don't think 'you can fight
City Hall', or whatever) have similar experiences? You really ignore and
reject this braod point at risk of being who believes in a view of
reality that is false. those who believe in false realities -- whether
religious, or philosophical, or technical -- are doomed to hit a brick
wall sooner or later. And seldom seem to even see it coming.

The only reason I was able to rather quickly diagnose this failure was
that I had happened to be 'browsing' some completely separate gcc
documentation within the last few days and had noticed this. To think
that this is "obvious" or a 'well-known issue' is I think far from the
obvious truth. 

> Anyway, this -fnative-struct vs. -mms-bitfields issue has already been
> reported, bug #93695. And I did of course know that something had to
> be done to it also before that bug report. Anyway, thanks for your
> patch to implement setting it depending on gcc version!

You are welcome. I think it's a good patch and I hope it gets into the
build file for Glib. You may find my tone or something in this reply
grating or provocative or insulting, if so I wish to again make a
gesture indicating my respect for you for your huge efforts to bring
GIMP to Win32, which I have long noticed and admired. But I won't be
swayed in my essential orientation and intention which is to
*emphatically* advocate on behalf of all those who are or will be where
I have been: struggling on the lower slopes of the *unbelievably steep*
learning curve that is GNU-based build configuration. There's this
widespread dogma out there that says that few people have been having
problems with it and, "after all, if they are working on Win32 they are
already experts or they wouldn't be trying to build GNU-ish packages
anyway". Almost no degree of invective would suffice to express how
resentful I feel I justifiably am on account of this blindness or warped
perspective on the part of people who have become comfortable and
dogmatic about Autotools. It has made people who write or maintain
Autotools-based 'configure' scripts complacent and mediocre about the
quality of their scripts and a huge part of the problem lies there. I
cannot even blame the maintainers of autoconf and its chums to the
degree that I blame the package maintainers out there for laziness and
lack of empathy and insight into what they are inflicting on their
users. 

Somehow in over-reliance on the whole Autotools system, package authors
/ maintainers have come to believe in a fantasy version of reality. 

For every build-bug report that a package author gets, there are going
to be 5 or 10 users (or more) who tried and just gave up -- threw up
their hands after hours of struggle and said "this just isn't worth it".
You, Tor, seem to have a discontinuity in YOUR perception of who "users"
are -- a dualistic extreme in which you don't recognize anything in the
middle between "GIMP-Win32 users who don't know (or care) what a DLL is"
on one hand and "people who can figure out for themselves an Autoconf
or compiler issue" on the other. There is in-between those extremes a
huge number of users who are being forced by such a view (which is not
yours alone but is unfortunately very widespread) into becoming de-facto
co-developers of GNU Autotools when that was never their original
interest. 

I'd LOVE to be just working on graphics with the GIMP right now, instead
of sweating all this Autotools-based inadequacy, these minute details
and obscure gotchas. While I am deriving satisfaction out of the present
progress I have been making in finally grasping how these things work
on a closer-to-expert level, it was NOT what I set out to do. I am
willing to do this work solely in order to benefit others -- so that
someone else doesn't have to. 

> > -dnl Initialize maintainer mode
> > +dnl Turn on maintainer mode to save users from Automake Hell.
> 
> I don't think GLib's configure.in is the right place for statements
> like this. Personaly, I don't think Automake is that bad. It's libtool
> which is the worst (most complex, hard to read, slow) of the auto*
> tools.

I do not give a damn whether anyone thinks it is appropriate. The brief
phrase "Automake Hell" does not even begin to convey how much trouble,
how many umpteen gazillion wasted man-hours has been caused by the
fundamental design decisions / policies of the 'automake' authors.
Placing it in a 'configure.ac' script that users might read is my
expression of my right to Free Speech (which somewhere along the line
WAS connected to what Free Software was supposed to be about) and what's
more, is done with the intention of emphasizing to anyone who is or
might become the author of a 'configure.ac' file or become a package
maintainer, just how crucial this belated Automake band-aide is (absent
any better cure for the badness that Automake inflicts on users). If
someone gets offended, well, GOOD, because this absurd situation has
been going on FAR too long and apparently nothing short of a sharp slap
in the face will wake up the people who are promulgating these problems
(and if you're not part of the solution, you are part of the problem.
Seldom did that saying ever hold so true as it does in this case). If
gentler measures and words could have worked they would done so a while
back. 

So, the phrase stays in. If that makes the patch unacceptable to the Glib 
maintainers, I really don't care. I'll maintain my own Website with the 
configuration build files authored as I see fit -- I'll 'fork' the build-
support for Glib -- and the few users who find their way there can benefit 
from it instead of the many users who just download the canonical source 
with blind faith that "because it's GNU, it ought to work".

In case it isn't clear yet, I am not going to budge on my views about how 
bad automake is. Somewhere there is an enormous schism between how you are 
seeing reality and how I am seeing it. I believe this schism is part of a 
deeply-embedded phenomenon in the present world of Open-Source / Free 
hacking in which the priorities of package maintainers are being set with 
an "if it's too much extra effort for me to do, i'll come up with a good 
argument / rationalization for why I shouldn't be expected to" attitude as 
a basic unacknowledged premise. Instead of admitting that they are 
promulgating software packages that are doing things based on accreted 
kruft and dumb habit, the kruft and the habit gets "blessed" as 
'convention' and 'standard'. The people who carry the burden of this staus 
quo are the users (in this discussion, I am *always* defining 'users' as 
'users who want to build from source') of broadly intermediate-level skill, 
knowledge and time resources.

IMO, any software developer or hacker should only ever ONCE run `automake' 
on their system, and that would be in order to generate a tutorial dir full 
of files that demonstrate the GNU conventions for Makefile build targets. 
Then s/he should use another means of building the Makefile support for 
his/er package using the tutorial as a guide of set of suggestions for what 
users will expect -- but NOT base regeneration of Makefiles on automake and 
NOT have to distribute the ridiculous number of required support files that 
use of Automake mandates, in their package distro. And the very LAST thing 
that should be happening is that *users* who want to just build the package 
from source, should EVER have to install or run Automake just to get build 
files that work. That this is so common and even becoming expected is a 
sure proof that Autotools as a whole system / ideology has failed to comply 
with its own initial theory and principles.

> > +AC_EXEEXT
> 
> Why does this has to move? I wouldn't want to move it without a
> reason...

I don't think it even has to be there and is just code bloat. If you call 
"AC_PROG_CC" or "AC_CANONICAL_HOST" then I believe this gets set anyway. 
Moving it was mostly (what I had in mind was) to call attention to that 
fact. Again, it's about Autoconf modernization issues with Glib's 
'configure.ac' file.

> >  case "$host" in
> > -  *-*-mingw*)
> > +     *mingw*)
> 
> This isn't necessary. Doesn't config.sub canonicalize "mingw32" into
> "i386-pc-mingw32"?
> 
> > -  AC_MSG_ERROR([*** pkg-config not found. See
> > http://www.freedesktop.org/software/pkgconfig/]) -fi
> > -
> > -if $PKG_CONFIG --atleast-pkgconfig-version 0.5 ; then
> > -  :
> > +  AC_MSG_WARN([*** pkg-config not found. See
> > http://www.freedesktop.org/software/pkgconfig/]) 
> >  else
> > -  AC_MSG_ERROR([*** pkg-config too old; version 0.5 or better
> > required.]) +  if $PKG_CONFIG --atleast-pkgconfig-version 0.5 ; then
> > +  :
> > +  else
> > +  AC_MSG_WARN([*** pkg-config too old; version 0.5 or better
> > required.]) +  fi


> Yes, this might be OK. Please file a bug report, especially for issues
> like this that aren't Win32 specific.

Not likely at this point. I am sufficiently re-aquainted with the congitive 
disconnect between users like me (who the 'priesthood' of GNU 
maintainership can all-to-easily dismiss as 'cranks' and 'ingorant 
newbies') by your response, that I just cannot feel it would be worth my 
time to try.

> > +# This next is a _severely_ deprecated macro.
> > +## AC_CYGWIN
> 
> Are you sure? People who have been building on Cygwin haven't
> complained. 

Read the documentation. Particularly the autoconf manual section on 
"deprecated macros".

    Regards,
     Soren A