[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Found process taking too much CPU: libtool

From: qm
Subject: Re: Found process taking too much CPU: libtool
Date: Sun, 26 Nov 2006 21:08:43 -0800

" On Nov 25, 2006, at 1:48 PM, address@hidden wrote:
" > whatever it is, it can be done in C, rather than shell scripts.
" >
" > I skimmed the home page.  It said portable.  C is portable.  Do it in
" > C.  I'm sure C is more portable than sh.  Regardless of how
" > religiously and/or politically correct C vs. sh is, libtool cannot any
" > longer be in sh because it is way, way, way, way, way, way too slow.
" Thanks for volunteering to do the rewrite.

Sure.  But time and knowledge constrained.  High probability of not
finishing task.  Does going to bed thinking about it count?

" I think you may have to learn what it does first though.

Upsettingly true.  I almost sat down and started coding it straight
from the shell script as a first stab without caring what it does,

* No time for even that
* I don't know if the shell script is generated from another source
  which is where the program structure should be started from.
* Convolution of shell scripts often necessary which makes its structure
  possibly orthogonal to C.  Not that C is straightforward; it doesn't
  give you the freedom of assembler.  However, it is standardized
  (yes, I know that its standardization is not pefect).

If the job of recoding in C is taken, then possibly an intermediary
incremental (even just porting) project could be done that just
incrementally implements libtool in C, leaving it as is except part by
part it gets recoded.  Perhaps an executable with jump points and
environment specification in it?  How to do shared memory with shell
script ... hm.  Always pass it all the necessary variables and have a
way to get back result.  Not sure.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]