On Thu, Feb 24, 2000 at 03:54:58AM -0500, Ezra Peisach wrote:
>
> I too am concerned with performance with libtool. I tried slipping
> libtool into a complicated package and the build time went from 1'20"
> to 2'00". Not the fastest of machines, but....
And as more features pile in, it will get worse I fear =(O|
Actually, I am more motivated by the maintainability aspect of the
huge shell scripts that libtool is become. But a good turn of speed
would be a huge benefit too =)O|
> I have read the threads on "u" and other crose-compiler issues...
>
> My thoughts:
>
> a) cross-compiling is an important issue - but I agree that whoever is
> doing the cross-compiling is likely to have a host compiler. If not,
> let us assume that they are using a verion of linux where they can get
> a package for libtool. Perhaps an autoconf macro that allows people to use
> a system installed version of libtool.
The precompiled `u' issue is bigger than just linux. Infact it is far
more likely that someone on Solaris (for example) will be without a
host compiler that someone on linux. But, yes, I agree that there is
no practical situation where someone will be completely unable to
cross-compile on a host -- just so long as they don't mind hunting
down a host compiler (probably a gcc binary dist for their
architecture). I hadn't thought about having a binary `u' dist for
these people though, and that is probably a better solution in some
cases, and much lighter than having to install a full host compiler
suite.
> There is the issue of making sure to use the host compiler to build
> libtool and the cross compiler should be used by libtool. I think the
> binutils package has already started working out these details.
libtool-2.0 shouldn't care about this. It will call (via `u') the
cross compiler or host compiler whenever binutils is involved.
> b) I think you are going with a rewrite in "C". Personally, I have no
> preference for a language - provided it is portable. Regarding
> flex/bison etc, I don't think it matters too much. (I assume this is
> in writing your `u' language to produce the libtool executable).
On the contrary, I want to write an interpreter in C, and then rewrite
libtool in the interpreted language. The main sticking point (other
than a lack of time for the last --and next-- few months) is designing
a language that is a best fit for the libtool probem space.
Particularly the future problem space. Well, that is very
hand-waving, of course I can't anticipate exactly where libtool will
be in a years time, but it is important that `u' doesn't hold it back.
> c) If you need help in your writing efforts, I am happy to provide assistance.
> As a person desiring the potential performance boost, I have a motivation for
> the rewrite to happen sooner rather than later.
That would be fantastic! I am currently prototyping an interpreter
which defines it's syntax with loadable modules. This will arrive on
my home page in a few weeks time, possibly sooner. At that point, I
(we!) will need to come up with the syntax necessary to provide the
functionality of the existing libtool scripts, and write modules for
the prototype interpreter while translating.
If you (or anyone else that is reading) is champing at the bit to
make a start on this, please find a block of code in ltmain.sh, and
try to come up with a tight syntax design to provide the same
functionality. If you want a pre-alpha of the prototype engine, I
can mail tarballs out, and then you can play with modules to implement
the syntax you have designed.
> Ezra Peisach
Cheers,
Gary.
--
___ _ ___ __ _ mailto:[EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
