🚀 go-pugleaf

Thanks, Nhi,  it worked.

Yes, time is an issue.  I am an aspiring hardware guy, so I've been learning
about software build procedures by reading web manuals on make, and by
endless trial/error.  Didn't help.  Also spent uncountable hours reading and posting to
mailing lists for various freeware to get it to run.  This is one of many freeware
solutions I've "thoroughly" investigated for my problem, each one involving a
sizable learning curve, and representing that much more catch-up to be done.
Doubtlessly, if my work involved expertise in software, I would have done it
faster, and I would have more expertise/familiarity/time with which to fix the
build scripts or even the source code.  But the most realistic thing for me to
do right now is to post my findings on the maling list for that freeware.  The time
just isn't available for me to become an expert with the build procedure, the
various compilers/interpretters to make it work, or especially the application
source code itself....I have tried looking at source code to solve a problem, and
it is completely incomprehensible, though I'm probably missing alot of information
required to make it meaningful.  The sheer quantity of it was mind boggling.
Even the list of files within the file tree is never-ending.  I'm sure that even the
task of understand the algorithms and that make it work, as well as the architecture
of the overall application, is nontrivial, much less the code itself.  I've done what
I could by putting in quite a bit of time carefully putting together an information and
summary package for this purpose, which sometimes includes information
about how to get around problems I've encountered.  Sometimes, it generates
comments, sometimes when it wasn't read carefully, but by-and-large, it's
not enough for the author to quickly duplicate the problem in his/her own
environment (it is a real problem when the problem only crops up in a very
big proprietary design).

Aside from that, the only other way I can realistically contribute is to show the
working application to as many people as I can.  Unfortunately, this hasn't turned
out to be straight forward either, and has itself entailed considerable time
learning about perl scripts to troubleshoot the failure when it is run in a different
environment from my own.  Still haven't figured it out yet.  So even though the
software is pretty good, and is free, it isn't simple to just jump in and contribute.
It seems it's all I can do just to make it work, and even then only sometimes.
This is after a heavy time investment trying several solutions that didn't
eventually pan out.  Eventually, I may be expert enough to fix build procedures
within a remotely manageable time (not source code), but spending even more
time to become such an expert is not an option right now, especially with the
fat frying.  In fact, building anything at all will probably be out of the books for a
while, for that reason. As you said, I guess.

Fred

--------------------------------------------------------------------------
Fred Ma
Department of Electronics
Carleton University, Mackenzie Building
1125 Colonel By Drive
Ottawa, Ontario
Canada     K1S 5B6
fma@doe.carleton.ca
==========================================================================

Nhi Vanye wrote:

> $ from fma@doe.carleton.ca -#133950 | sed "1,$s/^/> /"
> >
> >
> >I'm using solaris8.  The reason why I'm looking at the build script is because
> >there are many errors, and some syntax errors related to invalid switches.
> >It turns out they are only valid for the gnu versions of those programs.
>
> The "right" thing to do is to clean the code up so that it builds with
> the Solaris compilers, then send the diff back to the author of the
> application. It takes your time, but it improves the application (and
> you get to learn the differences betwenn gcc and the system compiler
> which means you're less likely to hit the same issues with code you
> write). People that put compiler specific flags in Imakefiles/Makefile.am
> should to be educated about portablilty, if all you have is one OS/tool
> set available you're not always aware of the implications.
>
> Hiding the problem by using gcc doesn't help anyone else who will try
> to do the same thing in 3months time, they'll have to try and debug this
> problem just as you have.
>
> But I realize that there's not always the time to do the right thing...
>
> >
> >Thanks.  I'll give it a go.
> >
> >Fred
>
> richard.
> --
> Richard Offer                         Technical Lead, Trust Technology.
> "Specialization is for insects"
> __________________________________________http://reality.sgi.com/offer/