[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 18:56:38 -0500
User-agent: Internet Messaging Program (IMP) H3 (4.0.2)

Quoting Bill Page <address@hidden>:

On April 16, 2007 12:22 PM wrote:
Quoting Bill Page <address@hidden>:
> On April 16, 2007 3:32 AM Gaby wrote:
>> I have a functional development environment under windows
>> -- cygwin -- but I cannot use it because GCL does not work
>> under cygwin
> What do you mean that GCL does not work under cygwin? It works
> for me. You just can't compile it under cygwin.
That means the same thing for me: If I cannot compile it under
cygwin, it does not work for me as far as Axiom development is

Why not? It is not necessary to build gcl as part of the Axiom
build - just install the windows binary for gcl, like other users
Windows do.

 (1) but I'm not like other windows users;  I'm doing something
     to Axiom that most of them -- if I understand your previous
     postings correctly.  I'm doing changes to Axiom, and I need
     to make sure that what was previously working (build Axiom
     with or without bundled GCL) is still working.

 (2) you would have to assume that although I'm facing build issues, I'm
     not totally dumb and there are reasons why I need to do what I'm
     doing, i.e. building GCL.
     Otherwise, I feel like after wasting time fighting the build
     issues under windows itself, I'm wasting time at being convinced
     that I really do not have time to waste on windows issues.

     What I'm looking for is way to get forward, given the constraints
     I enounciated.  I need automake-2.60 working, I need the ability
     to compile GCL, among other things.  If you know of no way that would
     let me do those, that is fine.  But, please don't waste time arguing
     why I need to compile GCL.

     I need to compile GCL as long as that is the only supported Lisp


What I want is to have a reasonable development under windows
-- whether it is mingw or cygwin, I don't care much.  The only
thing I care about is that the environment does not disrupt
me much from doing actual work.

MSYS/minGW works for me.

yes, I believed you.  The trouble is that it is not working for
me at the moment.  So, the fact that it works for you is good,
but at moment it does not help me make forward progress.

>> I guess the fact that windows people on this list don't
>> help that much to make concrete forward progress is OK.
> I think that is typical.
OK; I believe the logical conclusion for me is probably that
I drop any work on Axiom on windows.

Your choice.

Indeed.  If I had infinite amount of time, I may continue this
"windows entertainment", but I haven't.  And I don't have time for
infinite argumentation either.

Granted you can reproduce the problems, but the solution you
suggested did not work for me. I moved ActivePerl's path away
from /bin and /mingw/bin.

??? That doesn't sound right. Did you take a look at

I hoped it does not sound right.  But, that is what I'm experiencing.

MSYS looks in a lot of places besides /bin and /mingw/bin.

I know that; I may be clueless at how to solve the issue I'm
facing currently, but I'm exactly newbie in program and system
development.  I need a help that is more than "basic".

If ActivePerl is in your windows PATH, it will be accessible
to MSYS.

But, never used if its path is after /bin, where MSYS's perl resides.

But if you have /bin/perl installed it will be found by MSYS
first before ActivePerl.

I know that.  I need more than "101" stuff.


If your perl returns:

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

then that seems very strange. It works for me. And if I rename
/bin/perl  to something else (and thereby use ActivePerl from
windows), it fails that way you said it does for you.

I believed you when you said it worked for you.  I did believe there
was a way to get everything working -- that is why I originally said
that I was looking for a way to get a reasonable build environment
set up.  If you can't trust me, you can't help me :-)

But I already have MSYS pre-packaged components from!

So you are running "perl, v5.6.1 built for msys" or not?

yes -- if that was not clear, yes, yes, yes, yes.

> MSYS is not a linux distro by any imagination but I think the
> same principle applies.
Which implies that I should not even try your suggestion of
installing Autoconf-2.61 from a non-officially supported third
party.  I don't think your statements are coherent.

By your rules you would only do this if you had no other choice.
What choice do you have?

(1) stop sinking my time in this windows+axiom black hole
(2) get a way to get a reasonable build environment.

If you want to abandon Windows development
for build-improvements, fine, it's your choice. But would still
try to encourage you to continue.

so far, I've seen more "discouragement"; sorry to put it that way.
But, I'm sure there people on this list that can sort this out, so
my not working anymore on windows+axiom is not a big deal.

Bill -- again, building Autoconf-2.60 does not work on the
"virgin" msys/mingw fails as an infinite loop.

Very odd. I works fine for me:

$ wget

The "wget" that comes with msys/ming packaged does not work for me.
So I use ncftp to download tarballs.  I don't believe that changes
anything though.

$ tar xzvf autoconf-2.60.tar.gz
$ perl --version

This is perl, v5.6.1 built for msys

as I said, I already have that.

$ ./configure

this works fine.

$ make

this step, attempts to install things for me (which I was
surprised of), and goes into infinite loop.  There is no way
to effectively stop the build, except killing the msys shell

I move from Autoconf-2.5x to Autoconf-2.60 because:
  (1) it does fix a bug, that turns out to be serious in later
      development for Axiom (partly because of some bugs in Axiom).
  (2) all my development machines have Autoconf-2.60 installed
      (prepackages with the linux distribution).
As I see this, I can the reasonable choice for me is to stop any
work related to Axiom on windows; that save me valuable time, and
probably spares me from unwarranted unhelpful characterizations
and moralization.

Your choice. Maybe you can wait until someone produces an MSYS
developer package with 2.60 pre-installed. Again I apologize for
my "unwarranted unhelpful characterizations and moralization".
I have no excuse except to observe that it is common human failing.

apologies accepted.

If people care about Axiom on windows, they will find resources
to get it happen.

I doubt that very much. All that is likely to happen is that they
will dismiss Axiom as uninteresting.

then, I'm afraid Axiom is effectively uninteresting to them.  If the
Axiom community coming from windows users cannot find developers from
that community that understands them better than I do, it is unlikely
that Axiom will ever be of use to them.  Interested people usually
put their money whether their month is.

Consider for example Martin's
recent experience with promotion of his guess package for Axiom.

I'm sorry for Martin.

What I've learnt over the years working on several projects (usually
open source) and the C++ language is that if something is of interest
to you better make sure that you invest enough effort to meet the
interest.  It is unlikely that just waiting for something to happen
will effectively make that thing happen.  That certainly partly
explains, apart from natural research curiosity, why I spend resources
working on Axiom.

My current goal is to produce a version of Axiom for windows that
has this (and other bug fixes by Waldek) pre-installed. Right now
build-improvements is the best tool to accomplish this.

I was hoping to make it better, but I faced issues and I did not find
the kind of resources that would help me make progress.  I do hope
someone in this community has better chance that I.

-- Gaby

reply via email to

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