On Sun, 13 Oct 2002 15:57:46 -0400 (EDT)
Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Hello, Tom!
>
> If you are going to make a fork, add a well-behaving shell to the
> requirements and leave out everything else. I know a project with
> configure script longer than 500k. Uncompressed sources o
> Tom seems resistent on a backfill library of headers and
> library functions
Uh...actually, that's part of the intention of `libhackerlab' -- also
at the regexps.com ftp.
-t
> Uncompressed sources of ash with function support are smaller than
> that.
:-)
I've found that a few standard Posix tools, plus GNU Make, are a nice
combination (c.f. the `package-framework' via anonymous ftp from
regexps.com -- not that the framework is anywhere near done).
Pavel Roskin wrote:
> For example, there are two libraries, A and B, and only one can be used.
> There are at least (not counting --with-A=/path/to/A) 2 possibilities for
> each library (present and absent) and 3 possibilities for each option,
> (--with-A, -without-A, no option), which makes 36 c
Hello, Tom!
> The maintainers have to struggle to write portable shell code; they have
> to constantly avoid the temptation to introduce new tool dependencies in
> the wrong place; they can't even rely on GNU Make.
Maybe I'm missing something, but portable code is easier to maintain.
It's a si
Ok, those would be your goals for the non-bootstrapping fork.
Aside from obvious goals (like, "cleaner, simpler, cooler")
my vague idea is:
I want to make it much easier to audit installations and to automate
package dependency handling. I want to make it easier to construct
multiple user env
Tom Lord wrote:
>
> I personally pretty much agree with the larger picture you propose --
> but we can separate concerns.
>
> Forking the build tools projects is orthogonal to any particular
> direction to take the non-bootstrapping fork.
I don't think it orthoginal. If you separate them, then
I personally pretty much agree with the larger picture you propose --
but we can separate concerns.
Forking the build tools projects is orthogonal to any particular
direction to take the non-bootstrapping fork.
-t
From: Bruce Korb <[EMAIL PROTECTED]>
Organization: Home
X-Accept-Lan
> I guess this discussion is void - it is not about
> "forking". It is about creating your own set of buildtools
> and to try to reach a level of matureness that we see in the
> autotools today.
Yes and no.
Yes -- I have the nascent "package-framework" which has som
Tom Lord wrote:
>
> * Maintaining the build tools (autoconf etc) is currently too hard.
>
> The maintainers have to struggle to write portable shell code;
>
> Those constraints really matter to a small number of packages (the
> "bootstrap packages") but could be reasonably relaxed for other
Tom Lord wrote:
> are already installed. Call this set the "bootstrap packages".
>
> Let's then formally identify a _subset_ of the bootstrap packages,
> which are those GNU tools that other (non-bootstrap) GNU packages are
> allowed to depend on for the build process. For example, GNU Make
> w
* Maintaining the build tools (autoconf etc) is currently too hard.
The maintainers have to struggle to write portable shell code; they
have to constantly avoid the temptation to introduce new tool
dependencies in the wrong place; they can't even rely on GNU Make.
Those constraints really matte
Treeve Jelbert wrote:
>
> stray 'no' in link spec
>
> ---
Hi Libtool (& automake?),
Here's the Configuration:
> Source code location: .
> Compiler: gcc
> Compiler flags: -march=athlon -mmmx -m3dnow -O3
> Host System Type: i686-pc-linux-gnu
> Install pat
I don't have problems with 1.7 on my snapshot of snprintfv (which I can
publish in a matter of days on alpha.gnu.org). You can use it (but in the
meanwhile I just don't know what's the problem).
Paolo
- Original Message -
From: "Bruce Korb" <[EMAIL PROTECTED]>
To: "Automake Development"
14 matches
Mail list logo
