request consideration for aclocal.m4 modification

[Bill Fassler]

Ok, I can accept all that you say.  Although a seasoned software engineer, I am a complete novice when it comes to linux and open source software as I never used any of it until around 8 months ago, when I admit I leaned heavily on you guys and the ADI blackfin team who in all honestly basically helped tutor me. For that I am very grateful.  Alone it would have taken me 2 or 3 times as long to get to where I am at.

I am still lost in the imbroglio of the automake/autconf/libtool stuff.  It seems almost intangible at times how it all works.  Libtool especially causes more problems in cross-compiling to embedded platforms than it is worth (so it would seem to me at times)

I never meant to give the impression that I refuse to accept problems on my end.

I feel like I have been working through my problems myself (lately anyway), but I assume until I am good at this (which may be awhile yet) my analysis, solutions, conclusions and/or patches may be a half bubble off plumb.

I'll let you know if I figure out the root cause of this aclocal.m4 stuff and if and when I find the reason I can not build finch statically.

Bill

Ethan Blanton <elb at pidgin.im> wrote: 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
_______________________________________________
Devel mailing list
Devel at pidgin.im
http://pidgin.im/cgi-bin/mailman/listinfo/devel


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080229/6532ea46/attachment.html>