Lots of points to cover. I am not going to give equal coverage to all in this single reply...
Tor Lillqvist <[EMAIL PROTECTED]> wrote around 27 Sep 2002 news:[EMAIL PROTECTED]: > 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
