[Top][All Lists]

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

RE: [Axiom-developer] Re: Please join!

From: Bill Page
Subject: RE: [Axiom-developer] Re: Please join!
Date: Mon, 23 Apr 2007 02:32:04 -0400

On April 22, 2007 4:29 PM Waldek Hebisch wrote:
> Bill Page wrote:
> > On April 22, 2007 2:02 PM Alfredo Portes
> >
> > > Is Waldek branch able to compile in Windows or is it missing
> > > anything significant from build-improvements to achieve this?
> > > 
> > 
> > It is not possible (yet) to compile wh-sandbox on Windows.
> > I am working on it. Any help would be appreciated.
> > 
> Could you write what problems do you see?  Gaby wrote that on
> Windows one needs realtive paths -- this part in not merged
> into wh-sandbox (mechanical merge gives me build failures on
> Linux and the changes conflict with other patches that I am
> working on, so this will take some time).  

I am not convinced that it is necessary to use relative paths
but it does seem to be true that absolute paths can lead to
some trouble. The main cause of the trouble is the MSYS build
environment itself. The "base" of all paths in MSYS is the
root where MSYS was installed. So for example:

  $ cd /
  $ pwd
  $ pwd -W

The new option -W for pwd tells that actual Windows path using
/ where Windows normally uses \.

But if I pass a path beginning with / to a native Windows
application produced by MSYS then it does *not* treat / as
equivalent to 'C:\msys\1.0' but rather just 'C:\'. In MSYS it
is possible to specify an "absolute" path like this:

  $ cd /c/wspage
  $ pwd
  $ pwd -W

So that both MSYS and Windows agree on the "base", but of course
Windows applications do not understand '/c' as referring to
'c:\' unless there exists a link (windows short-cut) in the
root of the current drive with the name 'c' that points to 'c:\'.
This is possible, but awkard to create.

But in brief, this is kind of a mess in MSYS. There is a similar
situation in cygwin but in that case it does not cause problems
if you only build and use cygwin applications because the cygwin
library takes care of the path names. But this is not possible
in MSYS because the target applications are native windows apps.

The old axiom--windows--1 build for Axiom on Windows got around
this by very carefully using a combination of `pwd` and `pwd -W`
to get the right "absolute" path depending on whether it was a
path in an MSYS command or a path in the application code,

Gaby's solution to this problem is to use only relative paths.
Occassionally this looks a little weird with paths involving
unresolved things like 'src/share/doc/../../algebra' but at
least both Windows and the MSYS build environment treat these
the same way.

Another solution would be add a new concept of "base path" to
the build machinery so that windows applications like gcl and
the Axiom intermediaries are always given Windows absolute paths
while the MSYS tools see only MSYS absolute paths. But maybe
this would seem overly obscure to most linux developers.

There is also a problem in GCL on Windows when passing
arguments via -exec that contain subdirectory paths that
forces the use of echo and pipe, i.e.

  echo '(compile "foo/bar"

> Algebra and interp directories in wh-sandbox are significantly
> differenet than in build-improvements, but I hope that there
> is little (or maybe no) differences (beyond paths issues)
> affecting portability.

I think that is true.

> In other subdirectories of src the diff below summarizes 
> unmerged parts:
>  ...

I did not notice anything in the diff which might cause
problems (but then I often do not notice what the computer
seems to catch on almost every first attempt ... :)

In return I am sending you the following diff which shows the
current set of local changes that I have made to wh-sandbox
in an attempt to get it to compile under Windows. So far I am
still not successful. Some of these changes I may revert as
I find better ways to deal with the problems.

Index: src/Makefile.pamphlet
--- src/Makefile.pamphlet       (revision 512)
+++ src/Makefile.pamphlet       (working copy)
@@ -188,7 +188,7 @@
 all-lisp: all-lib
-       cd lisp && $(MAKE) all-lisp
+       cd lisp && $(MAKE) $(AX_FLAGS) all-lisp
Index: src/scripts/
--- src/scripts/    (revision 512)
+++ src/scripts/    (working copy)
@@ -1,3 +1,8 @@
+2007-04-10  Gabriel Dos Reis  <address@hidden>
+       * Don't use full internal name of symbols in package
+       boottran.  Push into that package first, and use short name.
 2006-11-22  Gabriel Dos Reis  <address@hidden>
        * (--tangle): Remove yucky hack.
Index: src/interp/Makefile.pamphlet
--- src/interp/Makefile.pamphlet        (revision 512)
+++ src/interp/Makefile.pamphlet        (working copy)
@@ -518,7 +518,7 @@
 In order for this information to be used during compiles we define
-PROCLAIMS=(progn (load "sys-pkg.lisp") (load
+PROCLAIMS=(progn (load "sys-pkg.lisp") (load
@@ -1110,12 +1110,14 @@
 $(addsuffix .$(FASLEXT), $(IN_from_MID)): \
     %.$(FASLEXT) : $(MID)/%.clisp
-       @ echo 10 making $@ from $<
-       @ ( B=`pwd`;\
+       @ echo 10 making $@ from $< hacked: WSP
+       @ ( \
+         # hacked to avoid windows path problem WSP
+         cp "$<" hacklocal.clisp ; \
          if [ -z "${NOISE}" ] ; then \
-          echo '(progn  (compile-file "$<" :output-file "'$$B/'$@")
(${BYE}))' | ${DEPSYS} ; \
+          echo '(progn  (compile-file "hacklocal.clisp" :output-file "$@")
(${BYE}))' | ${DEPSYS} ; \
          else \
-          echo '(progn  (compile-file "$<" :output-file "'$$B/'$@")
(${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
+          echo '(progn  (compile-file "hacklocal.clisp" :output-file "$@")
(${BYE}))' | ${DEPSYS} >> ${TMP}/trace ; \
          fi )
Index: src/interp/sys-pkg.lisp.pamphlet
--- src/interp/sys-pkg.lisp.pamphlet    (revision 512)
+++ src/interp/sys-pkg.lisp.pamphlet    (working copy)
@@ -29,8 +29,19 @@
 This is the boot to lisp compiler package which contains the
 src/boot files. Tt is the boot translator package.
+The following make-pkg command caused the error:
+Loading sys-pkg.lisp
+Correctable error: A package error occurred on "BOOTTRAN":
+"A package with this name already exists.".
+Signalled by MAKE-PACKAGE.
+So I have commented it out of the build. ...
+Bill Page, 21 April 2007
-(make-package "BOOTTRAN" :use '("LISP"))
+;; (make-package "BOOTTRAN" :use '("LISP"))
 Everything in axiom that the user references eventually shows
Index: src/lisp/Makefile.pamphlet
--- src/lisp/Makefile.pamphlet  (revision 512)
+++ src/lisp/Makefile.pamphlet  (working copy)
@@ -59,8 +59,8 @@
 \subsection{GCL already installed or built}
-<<build lisp for boot>>=
-## Create a fresh image for building Boot
+<<build augmented lisp>>=
+## Create a fresh image for building interpsys and AXIOMsys
 ## These objects files are the C runtime support
 ## and must be compiled into the Lisp image,
 ## as they must be present in the final interpreter
@@ -70,8 +70,9 @@
                $(build_libdir)/cfuns-c.o \
-$(OUT)/lisp$(EXEEXT): $(AXIOM_LISP)
-       echo '(compiler::link nil "${OUT}/lisp" ' \
+$(OUT)/lisp$(EXEEXT): initial-env.lisp
+       @axiom_gcl_rsym_hack@
+       echo '(compiler::link (quote ("initial-env.lisp")) "lisp" ' \
               ' (format nil "(progn (let ((*load-path* (cons ~S
                                         ' (si::*load-types* ~S))' \
                                        ' (compiler::emit-fn t))' \
@@ -79,9 +80,13 @@
                                         ' (si::sgc-on t))' \
                                   ' (setq compiler::*default-system-p*
t))"' \
                       ' si::*system-directory* (quote (list ".lsp")))' \
-               '  "$(lisp_c_objects)")' \
+               '  "$(lisp_c_objects) @axiom_c_runtime_extra@")' \
             | $(AXIOM_LISP)
+       $(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
+initial-env.lisp: $(srcdir)/../boot/initial-env.lisp.pamphlet
+       $(axiom_build_document) --tangle $< --output=$@
@@ -91,7 +96,7 @@
 pamphlets = Makefile.pamphlet
-build_libdir = $(abs_top_builddir)/src/lib
+build_libdir = ./$(top_builddir)/src/lib
 lisp_DEPENDENCIES = $(build_libdir)/cfuns-c.o \
                    $(build_libdir)/sockio-c.o \
@@ -102,7 +107,7 @@
 all-ax all-lisp: $(OUT)/lisp$(EXEEXT)
-<<build lisp for boot>>
+<<build augmented lisp>>
 # Build GCL takes quite a while, so we don't remove the
 # diretcory in mostlyclean.  Rather, we do that in clean.
Index: ChangeLog.wh
--- ChangeLog.wh        (revision 512)
+++ ChangeLog.wh        (working copy)
@@ -1,3 +1,10 @@
+2007-04-21  Bill Page <address@hidden>
+       * use echo ... | $command instead of -eval for build-prog
+       in
+       * apply revision 498 from build-improvements for LN_S
+        in and conf/var-defs
 2007-04-21  Waldek Hebisch  <address@hidden>
            Gabriel Dos Reis  <address@hidden>
            Humberto Ortiz-Zuazaga <address@hidden>
Index: config/
--- config/   (revision 512)
+++ config/   (working copy)
@@ -66,7 +66,12 @@
-LN_S = @LN_S@
+## FIXME:  The test done with Autoconf-2.60 and later concludes
+##         that "ln -s" is unusable on msys, and therefore defaults to
+##         "cp -p", but that default is unusable for us.  For our
+##         purpose "ln -s" is just fine on that platform.  Consequently
+##         we are explicitly overrding that value here.
+LN_S = ln -s
 mkinstalldirs = $(top_srcdir)/config/mkinstalldirs
@@ -102,23 +107,35 @@
 ## Notice, this is the src/ directory within the toplevel source
 ## directory 
-axiom_top_srcdir = @axiom_top_srcdir@
-axiom_src_srcdir = $(axiom_top_srcdir)/src
+axiom_src_srcdir = $(top_srcdir)/src
 axiom_src_docdir = $(axiom_src_srcdir)/doc
 axiom_src_datadir = $(axiom_src_srcdir)/share
 axiom_src_algdir = $(axiom_src_srcdir)/algebra
 ## Where tools for the build machine are built
-axiom_top_builddir = @abs_top_builddir@/build
-axiom_builddir = @axiom_builddir@
+# Tools that we occasionally build don't know
+# much about Autoconf and related infrastructure.  Therefore
+# we do lot by "hand". For the moment, things work if we specify
+# paths as absolute, as opposed to relative.  Other parts of
+# Axiom also expect absolute paths.
+axiom_abs_top_builddir = $(abs_top_builddir)
+axiom_abs_builddir = $(abs_top_builddir)/build/$(build)
+axiom_abs_build_bindir = $(axiom_abs_builddir)/bin
+axiom_abs_build_libdir = $(axiom_abs_builddir)/lib
+axiom_abs_build_mandir = $(axiom_abs_builddir)/man
+axiom_abs_build_datadir = $(axiom_abs_builddir)/share
+axiom_abs_build_texdir = $(axiom_abs_build_datadir)/texmf/tex
+axiom_top_builddir = $(top_builddir)/build
+axiom_builddir = $(axiom_top_builddir)/$(build)
 axiom_build_bindir = $(axiom_builddir)/bin
 axiom_build_libdir = $(axiom_builddir)/lib
 axiom_build_mandir = $(axiom_builddir)/man
 axiom_build_docdir = $(axiom_builddir)/doc
-axiom_build_texdir = $(axiom_builddir)/share/texmf/tex
+axiom_build_datadir = $(axiom_builddir)/share
+axiom_build_texdir = $(axiom_build_datadir)/texmf/tex
-axiom_configdir = $(abs_top_builddir)/config
+axiom_configdir = $(top_builddir)/config
 axiom_c_macros = $(axiom_configdir)/axiom-c-macros.h
---        (revision 512)
+++        (working copy)
@@ -1,3 +1,9 @@
+2007-04-10  Gabriel Dos Reis  <address@hidden>
+       * config/ (LN_S): Override.
+       * (<<file utils>>): Comment out test for
+       "ln -s".
 2006-12-03  Gabriel Dos Reis  <address@hidden>
        * (\subsubsection{Signals}): Ensure the
---       (revision 512)
+++       (working copy)
@@ -636,10 +636,20 @@
 \paragraph{File utils}
 Then, check for a usable [[install]] program.  Also, find out
-way to hard- or soft-link files.
+way to hard- or soft-link files.  
+After a recent migration to
+\Tool{Autoconf-2.60}, it turns out that all possibilities of
+soft-linking are tried (to ``play safe''), and if any variation
+fails then, [[LN_S]] is defined to [[cp -p]], which works
+only for files as sources.  But, the only way we currently
+use [[LN_S]] is when the first argument is a directory.  So, the 
+``portability help'' we get from \Tool{Autoconf} is no help.  
+Consequently, the test for
+[[ln -s]] is commented out for the moment.
 <<file utils>>=
 AC_CHECK_PROG([TOUCH], [touch],
               [touch], [AC_MSG_ERROR(['touch' program is missing.])])


Bill Page.

reply via email to

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