[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Axiom-developer] differences wh-sandbox andbuild-improvements

From: gdr
Subject: RE: [Axiom-developer] differences wh-sandbox andbuild-improvements
Date: Mon, 16 Apr 2007 02:31:43 -0500
User-agent: Internet Messaging Program (IMP) H3 (4.0.2)

Quoting Bill Page <address@hidden>:

On April 15, 2007 5:28 PM Gaby wrote:

Quoting Bill Page:

> On April 15, 2007 5:56 AM Gaby wrote:
> ...
> > my frustration with windows is only growing.
> >
> I think it best to avoid the trap that most linux
> developers fall into when working with Windows. As
> far as I am concerned it is just another operating
> system ...

Maybe -- I don't know what trap it is.

The "trap" to which I was referring has been called "Linux
chauvinism", see for example:

by Nikolai Bezroukov

In my own words its something like this: Assuming that because
one is having trouble in an environment with which one is less
familiar, that it is therefore inferior and a unnecessary source
of frustration - sort of opposite to the slogan: "familiarity
breeds contempt". It is a trap because believing this tends to
make it seem true.

But I did *not* intend to accuse you of this even by implication.
Sorry. It's just that I see this statement made very often in
different ways and I think it tends to perpetuate views that I
think are undesirable. However frustration, is of course quite

I have a functional development environment under windows -- cygwin --
but I cannot use it because GCL does not work under cygwin and I
have been told on this list that windows people don't care about
GCL under cygwin.  I guess the fact that windows people on this list don't
help that much to make concrete forward progress is OK.  Now, I've
been trying to set up a reasonable environment for working on Axiom
with no good result so far and I'm told by non-implicative non-accusation
that I would be suffering from trap known as "linux chauvinism" when nobody
knows what I think of comparison of linux and windows.  I guess that is
fair.  And my problems did not go away.  I guess that is forward progress.

I'm using m4-1.4.9 and ActivePerl-5.8.9 build 820.

> ...
> I have:
> $ perl --version
> This is perl, v5.6.1 built for msys

I suppose you meant ActivePerl-

Perl comes in two flavours from ActiveState the 5.6.x track and the
5.8.x track. Both are considered current releases. I have 5.8.8 in
my Windows installation but 5.6.1 in MSYS.

Bill Page wrote:
> My first guess is that your problem might have something to do
> with be the version of Perl that you are using. I have never
> used ActivePerl for buidling MSYS/MinGW apps.

Maybe.  But, again, the idea of using ActivePerl for msys/mingw
came from mingw website.  I did not pull it out of my hat.

Well, it was only my first guess. But just be sure I renamed my
MSYS /bin/perl to /bin/old_perl and restarted MSYS so that it
picks up ActivePerl- from my Windows installation. Now
I can reproduce the error that you reported:

$ perl --version

This is perl, v5.8.8 built for MSWin32-x86-multi-thread

$ cd autoconf-2.61

$ make clean

$ ./configure
$ make
autom4te_perllibdir='..'/lib AUTOM4TE_CFG='../lib/autom4te.cfg'
        ../bin/autom4te -B '..'/lib -B '..'/lib
        --language M4sh --cache '' --melt ./ -o
The system cannot find the path specified.
autom4te: need GNU m4 1.4 or later: /usr/local/bin/m4
make[1]: *** [] Error 1
make[1]: Leaving directory `/home/Administrator/autoconf-2.61/bin'
make: *** [all-recursive] Error 1


address@hidden ~/autoconf-2.61

>> > Apparently you can also install autoconf-2.61 and m4-1.4.7
>> > binaries from:
>> >
>> >
>> >
>> yes, i donwloaded the autoconf package from there last night;
>> I've not tried that version yet.
> Let me know how it turns out.

not well -- my Perl is not /bin/perl.

Do you mean that they assume that perl is in /bin/perl?

Yes. Have a look at autom4te.

>> ...
>> > Is there any particular reason you want to continue using
>> > the older version autoconf-2.60?
>> >
>> my three main linux boxes are running that version,
> I recommend that we go to autoconf-2.61 for all Axiom builds.

As long as you prepare and commit all my patches, I'm fine with

Gee, that sounds familiar. Where did I hear that before? Oh,
sorry. I forgot. This is the Axiom open source project - the
one where each developer chooses there own flavor and version
of the basic tools ... I with draw my recommendation. Let's
just all continue to do it our own way. ;)

I believe you got it wrong; even with a smiley.
There are several "rules" I've developed over the years, while
maintaining linux boxes, that include:
 (1) don't mess with "system" tools packaged by linux distros;
 (2) duplicating tools under /usr/local, sooner or later causes
 (3) install system tools under /usr/local only when they solve
     fundamental problems.

I suspect you'd have much more effective impact at explaining me
how automake-2.61 fare vis-a-vis the above three rules.

Bill Page.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]