axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: building wh-sandbox on Windows


From: Waldek Hebisch
Subject: [Axiom-developer] Re: building wh-sandbox on Windows
Date: Thu, 26 Apr 2007 23:17:58 +0200 (CEST)

Bill Page wrote:
> Waldek,
> 
> I have finally succeeded in building wh-sandbox on Windows. 
> I have attached the patch set with diffs against revision 515. 
> My approach was to introduce a "BASE" variable as I discussed
> in a previous email to allow the Windows applications to have
> a different absolute path than the MSYS tools used during the
> build. This is in contrast to Gaby's approach of making all paths
> relative. In the end this seemed like the shortest path to getting
> wh-sandbox to compile under Windows. 
> 
> Please let me know what you think about this approach. 
>

Congratulations.  Few quick remarks about the diff:

1) It does not apply cleanly to 515 (I had problem with
   README.build-improvements, configure.ac.pamphlet and
   src/interp/sys-pkg.lisp.pamphlet)
2) Some parts seem to be whitespace-only diff (differnces
   in whitespace probably are responsible for failures in 1)
3) Use of '(in-package \"boottran\")' in document.in is wrong,
   because in Ansi Lisp the package name here is case sensitive,
   so we want '(in-package \"BOOTTRAN\")'
4) Do you really need subshells in src/algebra/Makefile.pamphlet?
5) In src/interp/patches.lisp.pamphlet the first hunk inroduces
   conditionals for |$saturn| etc.  I prefer to set those
   variables unconditionally, because ATM there is _no_ platform
   on which choosing Saturn works.
6) We can avoid using pathnames during interpreter build by
   eliminationg int/interp subdirectory -- one reason for
   keeping this directory is that we want sane pathname handling
   at user level, so have to solve the underlying problem.  The
   same solution should work for build.  But if we have to use
   gross hacks to get around build problems then I prefer to
   move files to single directory.
7) In config/var-def.mk I ommited a few unused variables that Gaby
   added -- I feel that we should not slavishy copy the bloat
   created by autotools.  More preciesly, I do not like bloat
   in machine generated files but as long as thing are handled
   automatically such bloat is acceptable.  But we are
   maintaning var-def.mk by hand and bloat is a problem.  So
   I would like to have only usefull stuff in config/var-def.mk
   -- it looks that your patch copies a bunch of unused variables
   from build-improvements.
8) Concerning BASE variable: it does not look nice, but I do not
   think that other solutions would look better.
  
-- 
                              Waldek Hebisch
address@hidden 




reply via email to

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