[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [shell functions, was RE: solving of name conflicts inincluded.a]
From: |
Tom Lord |
Subject: |
Re: [shell functions, was RE: solving of name conflicts inincluded.a] |
Date: |
Fri, 6 Dec 2002 22:54:53 -0800 (PST) |
Are you volunteering to convert the shell functions in CVS
Libtool into non-shell-function code? I would like to see this
discussion go in a different direction. I would like to see a
list of the platforms known to NOT have shell functions in
their Bourne shells. My point is that there are systems out
there that Libtool does not support currently, even before it
had a shell function in it. So we're not trying to write code
that runs on every computer that ever existed, so there is a
trade off between portability and maintainability, and a line
to draw. I don't think it is reasonable for any of us to
decide where that line is if we don't know who it might effect.
Digital Eq.'s Ultrix is the only one I'm aware of, are there
any more?
As an unreasonably unemployed person, I don't (any ore/currently)
_volunteer_ for anything in the free software community, which I
consider to be economically dysfunctional.
I will offer to earnestly consider employment situations in which I
can both work on and supervise others working on an architectural
review and repair to libtool and the auto* tools. You can see
examples of my code review practices in the most recent (as of this
date) messages to the arch-users list archived under:
www.fifthvision.net/Arch
and you can see my functional prototype replacement for the current
auto* tools architecture in `package-framework' from ftp.regexps.com.
You should note that this prototype is designed in such a way that
rapid and cheap conversion of hacks from the auto* tools is practical.
Documents discussing the "bigger picture" of how this relates to
delivering customers value are also availble via private exchange, in
response to credible inquiries.
-t