" On Nov 25, 2006, at 1:48 PM, [EMAIL PROTECTED] 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, but: * 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. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
