request consideration for aclocal.m4 modification

[Ethan Blanton]

Bill Fassler spake unto us the following wisdom:
> I am using Gutsy Gibbon Ubuntu 7.10 and it would seem to me that my
> build environment is up to date.
> 
> automake (GNU automake) 1.10
> autoconf (GNU Autoconf) 2.61
> libtoolize (GNU libtool) 1.5.24
> intltoolize (GNU intltool) 0.36.2

This should all be fine.  I don't personally use automake 1.10, but I
have not heard reports of problems.

> I experience absolutely no problems until I try to compile
> pidgin/finch. I know this isn't any kind of real professional analysis
> nor is it definitive proof of anything, but since I don't have any
> problems with anything other than Pidgin/Finch I have a hard time
> accepting the fact that the problem(s) are solely with my environment.

You are correct, it's all more or less irrelevant.  There are some
_facts_ here which are important.  E.g., one of your problems was in
aclocal.m4; we don't create aclocal.m4.  It is created *locally*, on
your machine, but the 'aclocal' command.  We canot control its
contents.  If your autoconf subsequently has a problem with those
contents, we really cannot be responsible.  Decrying this fact is not
going to fix anything, it is simply wasting time that you could be
using finding the real problem.

There may be libpurple errors, here, and I believe we have fixed quite
a few errors over time.  The libpanel/ncurses problem is a Pidgin
problem (although, I thought I had fixed it; at the very least, I'm
pretyt sure I sent you a method of fixing it which is strictly more
correct than the patch you sent), and we should fix it.  I have that
on my list of things to look at, even -- but I'm not being paid to
port finch to an embedded product, so there are other things which
have to come first.

> I have no problem making the mods manually to get a shared finch
> executable and continue my attempts to obtain a 100% stand-alone
> static finch executable.  Despite numerous attempts I have yet to get
> Finch to cross-compile statically.  I am sure you think this is my
> environment also, even though I can get static builds of all other
> open source applications I am using.

It may or may not be your environment.  Certainly at least some of it
seems to be.  The fact that other applications build is not really
relevant here, either -- especially given that, as you have pointed
out several times, finch/libpurple require a number of dependencies
which none of your other applications use.  The _real_ point is that
_you_ have the system which isn't working, it's a special, nonstandard
system, and we can't see it or work on it.  For some of these issues,
we need solutions from you, not the other way around.  That's not to
say we don't want to help, but we simply don't have the information.
From our point of view (at least, from my point of view) it seems like
you periodically come dump a set of problems on us and expect free and
instantaneous answers, apparently without having tried to fix anything
yourself.  That may not be the case, but it's sure what it _looks_
like sometimes.  I actually think we work pretty hard to fix your
problems, all things considered.  You're the proverbial market segment
of one, yet you get a significant involvement of Pidgin developers and
regulars.

Now, none of this is to say you should stop working on this.  On the
contrary, I would love to see it fixed, because I suspect it will do
nothing but make our build process more robust.  However, regularly
asserting that the problem cannot be on your end -- when, to all
indications, you have no idea where the problem is -- is bound to rub
those who are helping you, for free, on their own time, the wrong way.

Why don't you start this next round of debugging with actually
_looking_ at the macros in aclocal.m4 which are failing, and figuring
out what the problem is?  Perhaps you could find out where they come
from, as well.  It sure sounds like they're intltool macros.  Looking
at the various steps of the process (aclocal.m4, configure,
configure/make failures) separately and trying to determine how the
failures at various stages of the process correlate is usually a good
way to actually _fix_ problems.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20080229/25f62650/attachment.sig>