[9fans] Gawk in 9front-ports

[9fans] Gawk in 9front-ports

[Jens Staal]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

There was a recent discussion about that it would be nice to have gawk on
Plan9.

The latest upstream version of gawk can now be built via 9front-ports. I
think/hope I built/ported it correctly, but it would be nice with
critique/feedback/testing.

I noticed in the Arch linux package that gawk comes with a couple of
dynamic libraries and a header. Are those also interesting to include in
the Plan9 package (then as static libraries ofcourse)?

[-- Attachment #2: Type: text/html, Size: 498 bytes --]

Re: [9fans] Gawk in 9front-ports

[arnold]

Hi.

Jens Staal <staal1978@gmail.com> wrote:

> There was a recent discussion about that it would be nice to have gawk on
> Plan9.
>
> The latest upstream version of gawk can now be built via 9front-ports. I
> think/hope I built/ported it correctly, but it would be nice with
> critique/feedback/testing.

Majorly cool! The first thing to check is that 'make check' passes.
Some tests depend on locales; those are OK if they fail, assuming you
don't have locale data for them. Others are only run if gawk was built
with the MPFR library, so those should be OK too if they're not run. If
there are failures in other tests, they should be investigated.

I assume you built from the released tarball? Version 4.1.3?

> I noticed in the Arch linux package that gawk comes with a couple of
> dynamic libraries and a header. Are those also interesting to include in
> the Plan9 package (then as static libraries ofcourse)?

Supplyinig them as static libraries would serve no purpose. Those
dynamic libraries are extensions (or plug-ins, if you will). Gawk
loads them vial dlopen() if requested to via an @load directive in
the source or the via the -l command line option.

I hope that dlopen works on Plan 9; if so it's necessary to build
the libraries in whatever way will work to support dlopen.

The extension facility is something we (the gawk developers) put a
lot of work into for the 4.1 release. I can supply pointers to doc
for anyone who is interested. Here's a simple example:

	$ gawk -lreaddir '{ print }' .
	2814749767529876/./d
	281474977052502/../d
	2814749767530561/.bashrc/f
	281474976885114/.bash_history/f
	14355223812503808/.bash_profile/f
	1407374884183439/.bzr.log/f
	281474976885116/.ex-sgml-rc/f
	281474976885117/.exrc/f
	...

The readdir extension returns directory entries as records in an
easily-parsed format: '/' is the field separator and the fields are
the inode, the name, and an optional single-letter file type indicator.

The doc has more examples.

I hope this helps. Please feel to contact me off-list if you need
more info / help.

Thanks!

Arnold

Re: [9fans] Gawk in 9front-ports

[Jens Staal]

On Tuesday 07 July 2015 06:27:55 arnold@skeeve.com wrote:
> Hi.
>
> Jens Staal <staal1978@gmail.com> wrote:
> > There was a recent discussion about that it would be nice to have gawk on
> > Plan9.
> >
> > The latest upstream version of gawk can now be built via 9front-ports. I
> > think/hope I built/ported it correctly, but it would be nice with
> > critique/feedback/testing.
>
> Majorly cool! The first thing to check is that 'make check' passes.
> Some tests depend on locales; those are OK if they fail, assuming you
> don't have locale data for them. Others are only run if gawk was built
> with the MPFR library, so those should be OK too if they're not run. If
> there are failures in other tests, they should be investigated.
>

OK thanks - I will look at that and try to make a mk file for "check" :)
I will also look at mpfr some time....

> I assume you built from the released tarball? Version 4.1.3?
>

Yes 4.1.3
below is the ports entry:

https://bitbucket.org/mveety/9front-ports/src/0bf6695dcad94d32c34a73ed3d71010bbdf2a66b/textproc/gawk/?at=default

I used an "external" gnulib which apart from the gnulib-derived object files
usually supplied in gawk also takes care of the wchar-related dependencies.

I also used a custom/manual config.h and a semi-automatically generated mk-
file (mkmk and manual editing) rather than the standard configure/make.
For the actual source, there were just a few things that needed patching so
configure/make under APE might also work.

> > I noticed in the Arch linux package that gawk comes with a couple of
> > dynamic libraries and a header. Are those also interesting to include in
> > the Plan9 package (then as static libraries ofcourse)?
>
> Supplyinig them as static libraries would serve no purpose. Those
> dynamic libraries are extensions (or plug-ins, if you will). Gawk
> loads them vial dlopen() if requested to via an @load directive in
> the source or the via the -l command line option.
>
> I hope that dlopen works on Plan 9; if so it's necessary to build
> the libraries in whatever way will work to support dlopen.

most likely not since the whole system is static...

>
> The extension facility is something we (the gawk developers) put a
> lot of work into for the 4.1 release. I can supply pointers to doc
> for anyone who is interested. Here's a simple example:
>
> 	$ gawk -lreaddir '{ print }' .
> 	2814749767529876/./d
> 	281474977052502/../d
> 	2814749767530561/.bashrc/f
> 	281474976885114/.bash_history/f
> 	14355223812503808/.bash_profile/f
> 	1407374884183439/.bzr.log/f
> 	281474976885116/.ex-sgml-rc/f
> 	281474976885117/.exrc/f
> 	...
>
> The readdir extension returns directory entries as records in an
> easily-parsed format: '/' is the field separator and the fields are
> the inode, the name, and an optional single-letter file type indicator.
>
> The doc has more examples.
>
> I hope this helps. Please feel to contact me off-list if you need
> more info / help.
>
> Thanks!
>
> Arnold

Re: [9fans] Gawk in 9front-ports

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On 7 July 2015 at 16:25, Jens Staal <staal1978@gmail.com> wrote:

> most likely not since the whole system is static...


The loaders support creating a module, with the -u and -x options, with
import and export tables,
which are type-checked, to be dynamically loaded. If the program you're
working with won't compile and load
statically with the -T option (external type checking), it's probably not
worth pursuing. The type checking can spot bugs that other
systems miss, as it did with Python. (A #define was present for one include
of an #ifdef'd structure but not for another,
so functions had different ideas about the layout.) There's an auxiliary
library libdynld that's needed to load a module,
that doesn't seem to be part of the distribution, but I probably have got
the bits.

[-- Attachment #2: Type: text/html, Size: 1292 bytes --]

Re: [9fans] Gawk in 9front-ports

[erik quanstrom]

On Mon Jul  6 19:40:45 PDT 2015, staal1978@gmail.com wrote:

> There was a recent discussion about that it would be nice to have gawk on
> Plan9.

i'm confused.  wasn't there also an effort to un-apeify the one true awk?

- erik

Re: [9fans] Gawk in 9front-ports

[Kurt H Maier]

Quoting erik quanstrom <quanstro@quanstro.net>:

> i'm confused.  wasn't there also an effort to un-apeify the one true awk?


Yes, but as usual, we were shouted down by mac users.

khm

Re: [9fans] Gawk in 9front-ports

[Hugo Rivera]

Why do you want gawk on plan9?
I use awk a lot (on plan9 and elsewhere) and I wonder what reasons do
you have to use gawk over plan9's awk.

2015-07-06 22:37 GMT-04:00 Jens Staal <staal1978@gmail.com>:
> There was a recent discussion about that it would be nice to have gawk on
> Plan9.
>
> The latest upstream version of gawk can now be built via 9front-ports. I
> think/hope I built/ported it correctly, but it would be nice with
> critique/feedback/testing.
>
> I noticed in the Arch linux package that gawk comes with a couple of dynamic
> libraries and a header. Are those also interesting to include in the Plan9
> package (then as static libraries ofcourse)?



--
Hugo

Re: [9fans] Gawk in 9front-ports

[arnold]

Hugo Rivera <uair00@gmail.com> wrote:

> Why do you want gawk on plan9?

I appreciate knowing about portability issues. :-)

> I use awk a lot (on plan9 and elsewhere) and I wonder what reasons do
> you have to use gawk over plan9's awk.

Many features and extensions over standard awk. Different people will
assign different levels of value to said features and extensions.
A partial list:

- The previously discussed dynamic plug-in facility
- And awk-level debugger
- A statement count profiler (and a pretty printer)
- True arrays of arrays
- Many more built-in functions and variables. In retrospect, some of these
  are just bloat and I'd have been better off without them.

Arnold

Re: [9fans] Gawk in 9front-ports

[Jens Staal]

On Tuesday 07 July 2015 16:45:59 Charles Forsyth wrote:
> The loaders support creating a module, with the -u and -x options, with
> import and export tables,
> which are type-checked, to be dynamically loaded. If the program you're
> working with won't compile and load
> statically with the -T option (external type checking), it's probably not
> worth pursuing. The type checking can spot bugs that other
> systems miss, as it did with Python. (A #define was present for one include
> of an #ifdef'd structure but not for another,
> so functions had different ideas about the layout.) There's an auxiliary
> library libdynld that's needed to load a module,
> that doesn't seem to be part of the distribution, but I probably have got
> the bits.

This sounds very interesting. If it is availiable, it would be interesting to
spin in to a independent lib that could be re-used for various software that
expect/depend on dlopen.

Re: [9fans] Gawk in 9front-ports

[Hugo Rivera]

Let me understand. Are you going to modify the current gawk version
according to your needs (perhaps removing some of the bloat you
mention)? or are you going to port gawk as it is?

2015-07-08 2:22 GMT-04:00  <arnold@skeeve.com>:
> Hugo Rivera <uair00@gmail.com> wrote:
>
>> Why do you want gawk on plan9?
>
> I appreciate knowing about portability issues. :-)
>
>> I use awk a lot (on plan9 and elsewhere) and I wonder what reasons do
>> you have to use gawk over plan9's awk.
>
> Many features and extensions over standard awk. Different people will
> assign different levels of value to said features and extensions.
> A partial list:
>
> - The previously discussed dynamic plug-in facility
> - And awk-level debugger
> - A statement count profiler (and a pretty printer)
> - True arrays of arrays
> - Many more built-in functions and variables. In retrospect, some of these
>   are just bloat and I'd have been better off without them.
>
> Arnold
>



--
Hugo

Re: [9fans] Gawk in 9front-ports

[arnold]

Hi Hugo. I'm not sure who you're addressing. Jens did the port.
I maintain gawk.

Removing bloat unfortunately isn't going to happen in the mainline
code base since there are backward compatibility issues.

However, I'm happy to incorporate portability changes to make porting
to Plan 9 easier, if they're reasonable.

HTH,

Arnold

Hugo Rivera <uair00@gmail.com> wrote:

> Let me understand. Are you going to modify the current gawk version
> according to your needs (perhaps removing some of the bloat you
> mention)? or are you going to port gawk as it is?
>
> 2015-07-08 2:22 GMT-04:00  <arnold@skeeve.com>:
> > Hugo Rivera <uair00@gmail.com> wrote:
> >
> >> Why do you want gawk on plan9?
> >
> > I appreciate knowing about portability issues. :-)
> >
> >> I use awk a lot (on plan9 and elsewhere) and I wonder what reasons do
> >> you have to use gawk over plan9's awk.
> >
> > Many features and extensions over standard awk. Different people will
> > assign different levels of value to said features and extensions.
> > A partial list:
> >
> > - The previously discussed dynamic plug-in facility
> > - And awk-level debugger
> > - A statement count profiler (and a pretty printer)
> > - True arrays of arrays
> > - Many more built-in functions and variables. In retrospect, some of these
> >   are just bloat and I'd have been better off without them.
> >
> > Arnold
> >
>
>
>
> --
> Hugo

Re: [9fans] Gawk in 9front-ports

[Jens Staal]

On Thursday 09 July 2015 02:49:53 arnold@skeeve.com wrote:
> However, I'm happy to incorporate portability changes to make porting
> to Plan 9 easier, if they're reasonable.

For portability changes, I think not much is needed.

There was an issue with a duplciate case in posix/gawkmisc.c ,(S_IFSOCK
S_IFIFO, S_IFIFO is defined as S_IFSOCK in APE).
I also did a "hack" patch to builtin.c because it somehow forgot the
definition of uint32_t and I could not figure out why.

Other than that, most of the work was manual generation of config.h, mkfile
which are things that also should work with configure/make (but I have not
tried it). I added  <inttypes.h> and  <sys/time.h>  in config.h because some
source files assumed that those headers would be pulled in via other headers.
That hack would probably be better to put in custom.h.

As external dependency, we need some extra gnulib functions (wchar related
stuff). If we can get the dlopen thing to work by using this libdynld
(apparently from inferno origin, but once ported to nix-os), that would be
very cool.

As a porter, my prime aim is to stay as true as possible to the intent of the
developer and the expectations of the users. Basically, I do porting as a
"simple mental task to relax (like puzzles, cross word or soduko)". For most
of you real programmers the stuff I do most likely seems menial and pointless.
My "process"
1. can the porting be done?
2. does it work as expected?
3. (bonus) does anyone find it useful?

Re: [9fans] Gawk in 9front-ports

[Steve Simon]

FWIW: fgb did a stirling script called config which sets up some
environment and runs configure under ape. It doesn't always work but often gets close
to generating a config.h as linux intended.

-Steve

Re: [9fans] Gawk in 9front-ports

[Jeff Sickel]

> On Jul 9, 2015, at 5:19 AM, Steve Simon <steve@quintile.net> wrote:
> 
> FWIW: fgb did a stirling script called config which sets up some
> environment and runs configure under ape. It doesn't always work but often gets close
> to generating a config.h as linux intended.

Configure predates Linux.  That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register.

-jas

… at least you’re not using Xenix

Re: [9fans] Gawk in 9front-ports

[Hugo Rivera]

Arnold,
I am not sure who I am addressing either :-) Just wanted to know where
this gawk port was heading.
The thing is that I use a slightly modified version of Plan 9's awk.
In this version, I added all the math functions from C and replaced
the random number generator by the Mersenne twister.
As a comment, from my experience gawk is generally faster than Plan
9's awk, but I believe the latter is more reliable (it crashes less
often than gawk).
Please, let me (us) know about the future of awk in 9front.

2015-07-09 4:49 GMT-04:00  <arnold@skeeve.com>:
> Hi Hugo. I'm not sure who you're addressing. Jens did the port.
> I maintain gawk.
>
> Removing bloat unfortunately isn't going to happen in the mainline
> code base since there are backward compatibility issues.
>
> However, I'm happy to incorporate portability changes to make porting
> to Plan 9 easier, if they're reasonable.
>
> HTH,
>
> Arnold
>
> Hugo Rivera <uair00@gmail.com> wrote:
>
>> Let me understand. Are you going to modify the current gawk version
>> according to your needs (perhaps removing some of the bloat you
>> mention)? or are you going to port gawk as it is?
>>
>> 2015-07-08 2:22 GMT-04:00  <arnold@skeeve.com>:
>> > Hugo Rivera <uair00@gmail.com> wrote:
>> >
>> >> Why do you want gawk on plan9?
>> >
>> > I appreciate knowing about portability issues. :-)
>> >
>> >> I use awk a lot (on plan9 and elsewhere) and I wonder what reasons do
>> >> you have to use gawk over plan9's awk.
>> >
>> > Many features and extensions over standard awk. Different people will
>> > assign different levels of value to said features and extensions.
>> > A partial list:
>> >
>> > - The previously discussed dynamic plug-in facility
>> > - And awk-level debugger
>> > - A statement count profiler (and a pretty printer)
>> > - True arrays of arrays
>> > - Many more built-in functions and variables. In retrospect, some of these
>> >   are just bloat and I'd have been better off without them.
>> >
>> > Arnold
>> >
>>
>>
>>
>> --
>> Hugo
>



--
Hugo

Re: [9fans] Gawk in 9front-ports

[Jens Staal]

On Thursday 09 July 2015 11:19:33 Steve Simon wrote:
> FWIW: fgb did a stirling script called config which sets up some
> environment and runs configure under ape. It doesn't always work but often
> gets close to generating a config.h as linux intended.

part of that script is already "fixed" since I managed to get " -plan9* '
added to the list of OSes in config.sub upstream some years ago.

Re: [9fans] Gawk in 9front-ports

[erik quanstrom]

confirmed.  it's existence is due to early gnu programs fighting with small variations in unix and compilers.  byron's rc used a small script to the same effect.  but for the most part, this all could be avoided with careful planning and not using esoteric functions.  

gcc also had its own configuration step.  the header rewriting is a vestage of this system.

- erik


On Jul 9, 2015 05:31, Jeff Sickel <jas@corpus-callosum.com> wrote:
>
>
> > On Jul 9, 2015, at 5:19 AM, Steve Simon <steve@quintile.net> wrote: 
> > 
> > FWIW: fgb did a stirling script called config which sets up some 
> > environment and runs configure under ape. It doesn't always work but often gets close 
> > to generating a config.h as linux intended. 
>
> Configure predates Linux.  That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register. 
>
> -jas 
>
> … at least you’re not using Xenix 
>
>
>

[9fans] origins of configure

[arnold]

So, the history is more than this.

Larry Wall's Configure (capital C) for rn and Perl was the first step
at a shell script to examine system features and generate a config.h.
It was inspirational for autoconf, but autoconf doesn't use any of
its code, as far as I know.

Autoconf was designed to solve real portability problems. In the late 80s
and early 90s there was a huge variety of Unix systems and it was really
hard to know what was available and what wasn't based on simple ifdefs.
The variations were bigger than Erik makes out.

Today, the scale of the problem is reduced, since we have POSIX and
also fewer systems out there. Much of the bloat in the Autotools is
from legacy. But there are still very real portability issues, especially
among some of the fringe *BSD systems. MirBSD in particular is one of
the worst, but that's another rant.

If one were to start over today, one could likely arrive at a simpler
system, but portability problems remain, and they are real.

Arnold


erik quanstrom <quanstro@quanstro.net> wrote:

> confirmed.  it's existence is due to early gnu programs fighting with
> small variations in unix and compilers.  byron's rc used a small script
> to the same effect.  but for the most part, this all could be avoided
> with careful planning and not using esoteric functions.
>
> gcc also had its own configuration step.  the header rewriting is a vestage of this system.
>
> - erik
>
>
> On Jul 9, 2015 05:31, Jeff Sickel <jas@corpus-callosum.com> wrote:
> >
> >
> > > On Jul 9, 2015, at 5:19 AM, Steve Simon <steve@quintile.net> wrote: 
> > > 
> > > FWIW: fgb did a stirling script called config which sets up some 
> > > environment and runs configure under ape. It doesn't always work but often gets close 
> > > to generating a config.h as linux intended. 
> >
> > Configure predates Linux.  That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register. 
> >
> > -jas 
> >
> > … at least you’re not using Xenix 
> >
> >
> >
> From 9fans-bounces@9fans.net  Thu Jul  9 07:52:09 2015
> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
> 	frenzy.freefriends.org
> X-Spam-Level: 
> X-Spam-Status: No, score=0.0 required=5.0 tests=TIME_LIMIT_EXCEEDED
> 	autolearn=unavailable version=3.3.1
> X-Envelope-From: 9fans-bounces@9fans.net
> Return-Path: <9fans-bounces@9fans.net>
> X-Virus-Scanned: by MailRoute
> Date: Thu, 09 Jul 2015 06:50:06 -0700
> X-Android-Message-ID: <8f71c132-1b4d-4d0c-a741-d0738945f22c@email.android.com>
> From: erik quanstrom <quanstro@quanstro.net>
> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> Content-Type: text/plain; charset=utf-8
> Subject: Re: [9fans] Gawk in 9front-ports
> X-BeenThere: 9fans@9fans.net
> X-Mailman-Version: 2.1.13
> Precedence: list
> Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net>
> List-Unsubscribe: <http://mail.9fans.net/options/9fans>,
> 	<mailto:9fans-request@9fans.net?subject=unsubscribe>
> List-Archive: <http://mail.9fans.net/private/9fans>
> List-Post: <mailto:9fans@9fans.net>
> List-Help: <mailto:9fans-request@9fans.net?subject=help>
> List-Subscribe: <http://mail.9fans.net/listinfo/9fans>,
> 	<mailto:9fans-request@9fans.net?subject=subscribe>
> Sender: 9fans-bounces@9fans.net
> Errors-To: 9fans-bounces@9fans.net
> X-MIME-Autoconverted: from base64 to 8bit by freefriends.org id t69Dq5Ri006148
> Status: R
>
> confirmed.  it's existence is due to early gnu programs fighting with small variations in unix and compilers.  byron's rc used a small script to the same effect.  but for the most part, this all could be avoided with careful planning and not using esoteric functions.  
>
> gcc also had its own configuration step.  the header rewriting is a vestage of this system.
>
> - erik
>
>
> On Jul 9, 2015 05:31, Jeff Sickel <jas@corpus-callosum.com> wrote:
> >
> >
> > > On Jul 9, 2015, at 5:19 AM, Steve Simon <steve@quintile.net> wrote: 
> > > 
> > > FWIW: fgb did a stirling script called config which sets up some 
> > > environment and runs configure under ape. It doesn't always work but often gets close 
> > > to generating a config.h as linux intended. 
> >
> > Configure predates Linux.  That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register. 
> >
> > -jas 
> >
> > … at least you’re not using Xenix 
> >
> >
> >
>

Re: [9fans] origins of configure

[tlaronde]

On Thu, Jul 09, 2015 at 09:24:57AM -0600, arnold@skeeve.com wrote:
> So, the history is more than this.
>
> Larry Wall's Configure (capital C) for rn and Perl was the first step
> at a shell script to examine system features and generate a config.h.

Using a shell script to generate commands to compile on diverging Unices
was, by the date, already used in G.R.A.S.S. from C.E.R.L. and this
predates Perl and so on. I guess it is not the only example.

>[...]
> Autoconf was designed to solve real portability problems.

There are two problems with the autotools stuff:

1) Features are fixed for OSes, but the configuring is done other and
other again for every program. What a system offers shall be known; and
what the developers require shall be known too. Autotools was designed
in a world where neither the OS nor the developers exactly know what
they use;

2) Cross-compilation was not in mind, with some features tested by
compiling and running programs. The result is that the majority of
software built with autotools needs to be compiled natively (even
installed on an equal system since the layout is searched on the
building node);

3) To try to understand what's going on with several steps and huge
configs is out of reach.

Rule: when it takes less time to build a solution from scratch than to
try to understand how to _use_ an existing solution (not to mention
understand), this solution has to be safely stored in /dev/null.

Note: I have put my money where my mouth is : I have built such a
solution: the one publicly used with kerTeX---but it is a side
effect, it was not meant to be released.  And it solves the 1) and
2) and solves too the space problem: when an object is not any
longer necessary, it can be automatically removed, limiting the
space needed to compile to the bare minimum.

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] origins of configure

[arnold]

I don't intend to engage in yet another 9fans flame war.  I do not
argue with your analysis or proposal. However, it's based on considerable
hindsight and experience that wasn't available when autotools started.
Additionally, systems in that time period were changing continually.
So it was not always true that what any given system provides is known
in advance.

The autotools (and especially gnulib) are bloated. A better design
is possible.  But it's unfair to say that at the time they could
have done a lot better; I don't think that's true. "Hindsight is
always 20/20".

That's all I'll say on the topic.

Arnold

tlaronde@polynum.com wrote:

> On Thu, Jul 09, 2015 at 09:24:57AM -0600, arnold@skeeve.com wrote:
> > So, the history is more than this.
> >
> > Larry Wall's Configure (capital C) for rn and Perl was the first step
> > at a shell script to examine system features and generate a config.h.
>
> Using a shell script to generate commands to compile on diverging Unices
> was, by the date, already used in G.R.A.S.S. from C.E.R.L. and this
> predates Perl and so on. I guess it is not the only example.
>
> >[...]
> > Autoconf was designed to solve real portability problems.
>
> There are two problems with the autotools stuff:
>
> 1) Features are fixed for OSes, but the configuring is done other and
> other again for every program. What a system offers shall be known; and
> what the developers require shall be known too. Autotools was designed
> in a world where neither the OS nor the developers exactly know what
> they use;
>
> 2) Cross-compilation was not in mind, with some features tested by
> compiling and running programs. The result is that the majority of
> software built with autotools needs to be compiled natively (even
> installed on an equal system since the layout is searched on the
> building node);
>
> 3) To try to understand what's going on with several steps and huge
> configs is out of reach.
>
> Rule: when it takes less time to build a solution from scratch than to
> try to understand how to _use_ an existing solution (not to mention
> understand), this solution has to be safely stored in /dev/null.
>
> Note: I have put my money where my mouth is : I have built such a
> solution: the one publicly used with kerTeX---but it is a side
> effect, it was not meant to be released.  And it solves the 1) and
> 2) and solves too the space problem: when an object is not any
> longer necessary, it can be automatically removed, limiting the
> space needed to compile to the bare minimum.
>
> --
>         Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
>                      http://www.kergis.com/
>                      http://www.arts-po.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C