| olebole |
05/18/2014 03:01PM (Read 9709 times)
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Hi,
I am trying to compile the new 2.16.1 directly from the sources.
However, already the first command fails ($HOME/.iraf is empty):
TXT Formatted Code $ ./install
Initializing /home/ole/.iraf directory .....
[...]
========================================================================
===================== Verifying System Settings ======================
========================================================================
Hostname = poch OS version = Linux 3.13.0-27-generic
Architecture = linux64 HSI arch = linux64
Old iraf root = /iraf/iraf New iraf root = /home/ole/Projects/2011/debian/iraf/2.16.1/src
Old imdir = /iraf/imdir New imdir = /home/ole/.iraf/imdir/
Old cache = /iraf/cache New cache = /home/ole/.iraf/cache/
Local bin dir = /home/ole/.iraf/bin
Proceed (yes):
[...]
Checking File Permissions
-------------------------
Checking iraf file permissions ... [ FAIL ]
*** File
*** File
[...]
========================================================================
================= Installation Completed With Errors =================
========================================================================
When I try to ignore this, the following happens:
TXT Formatted Code make linux64 && make sysgen
[... lots of compilation ...]
+ gcc -c -I/home/ole/.iraf/ -g -DLINUX -DREDHAT -DPOSIX -DSYSV -DLINUX64 -DMACH6
4 -Wall -m64 -DNOVOS osfn2vfn.c
In file included from /home/ole/.iraf/iraf.h:28:0,
from osfn2vfn.c:11:
/home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/hlib/libc/libc.h:325:37: fatal error: /iraf/iraf/unix/bin/f2c.h: Datei oder Verzeichnis nicht gefunden
#include "/iraf/iraf/unix/bin/f2c.h"
^
compilation terminated.
[...]
+ echo ----------------------- MKPKG --------------------------
----------------------- MKPKG --------------------------
+ cd mkpkg
+ sh -x mkpkg.sh
+ gcc -c -I/home/ole/.iraf/ -g -DLINUX -DREDHAT -DPOSIX -DSYSV -DLINUX64 -DMACH64 -Wall -m64 -DNOVOS char.c fdcache.c fncache.c host.c main.c pkg.c scanlib.c sflist.c tok.c
host.c: In function ‘h_updatelibrary’:
host.c:104:10: warning: variable ‘lname’ set but not used [-Wunused-but-set-variable]
char *lname = NULL;
^
scanlib.c: In function ‘h_scanlibrary’:
scanlib.c:73:6: warning: variable ‘len’ set but not used [-Wunused-but-set-variable]
int len=0, len_arfmag, nmodules;
^
+ gcc -I/home/ole/.iraf/ -m64 main.o char.o fdcache.o fncache.o host.o pkg.o scanlib.o sflist.o tok.o /home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/hlib/libboot.a /home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/hlib/libos.a -o mkpkg.e
host.o: In Funktion `h_rebuildlibrary':
/home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/boot/mkpkg/host.c:290: Nicht definierter Verweis auf `vfn2osfn'
host.o: In Funktion `h_incheck':
/home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/boot/mkpkg/host.c:328: Nicht definierter Verweis auf `vfn2osfn'
host.o: In Funktion `h_outcheck':
/home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/boot/mkpkg/host.c:406: Nicht definierter Verweis auf `vfn2osfn'
/home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/boot/mkpkg/host.c:410: Nicht definierter Verweis auf `vfn2osfn'
host.o: In Funktion `h_copyfile':
/home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/boot/mkpkg/host.c:534: Nicht definierter Verweis auf `vfn2osfn'
host.o:/home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/boot/mkpkg/host.c:535: Weitere nicht definierte Verweise auf `vfn2osfn' folgen
collect2: error: ld returned 1 exit status
[...]
make[1]: Betrete Verzeichnis '/home/ole/Projects/2011/debian/iraf/2.16.1/src/vendor'
(./mklibs)
Building support libraries ....
(Using toplevel directory '/home/ole/Projects/2011/debian/iraf/2.16.1/src/' ....)
Building CFITSIO libs ....done
Building Readline libs ....mkpkg: Command not found.
done
Building VOClient libs ....done
make[1]: Verlasse Verzeichnis '/home/ole/Projects/2011/debian/iraf/2.16.1/src/vendor'
util/mksysgen: Zeile 60: mkpkg: Kommando nicht gefunden.
util/mksysgen: Zeile 64: mkpkg: Kommando nicht gefunden.
util/mksysgen: Zeile 68: mkpkg: Kommando nicht gefunden.
Start: So 18. Mai 16:52:40 CEST 2014
End: So 18. Mai 16:53:53 CEST 2014
So 18. Mai 16:53:53 CEST 2014
What is wrong here?
Best regards
Ole
(System is unpatched)
|
| |
|
|
| olebole |
|
05/18/2014 03:18PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
The second problem (with "make sysgen") seems to be fixable with the foillowing patch:
PATCH Formatted Code --- a/unix/hlib/libc/libc.h
+++ b/unix/hlib/libc/libc.h
@@ -322,8 +322,8 @@
/*
*/
-#include "/iraf/iraf/unix/bin/f2c.h"
-#include "/iraf/iraf/unix/hlib/libc/vosproto.h"
+#include "../../f2c/f2c.h"
+#include "vosproto.h"
#define D_libc
#define D_libc_proto
However, then I get a lots of errors like
TXT Formatted Code aclrc.c:6:18: fatal error: iraf.h: Datei oder Verzeichnis nicht gefunden
#include
^
compilation terminated.
and the compilation finishes with
TXT Formatted Code xc -Nz -/g -/m64 -p vo -p noao x_votools.o libpkg.a -lasttools -lxtools -lstg -lds -ltbtables -lslalib -o xx_votools.e
gcc: error: libVO.a: Datei oder Verzeichnis nicht gefunden
HSI is compiled NOVOS
HSI is compiled NOVOS
Warning, mkpkg line 7: module `relink' not found or returned error
move `xx_votools.e' to `vobin$x_votools.e'
$move: file `xx_votools.e' not found
Warning, mkpkg line 20: error moving file xx_votools.e
Warning, mkpkg line 8: module `install' not found or returned error
Warning, mkpkg line 10: module `update@votools' not found or returned error
Warning, mkpkg line 3: module `update' not found or returned error
Start: So 18. Mai 17:06:48 CEST 2014
End: So 18. Mai 17:14:19 CEST 2014
So 18. Mai 17:14:19 CEST 2014
I started from with a plain installation without previous IRAF installation in /iraf/ and with a removed $HOME/.iraf path.
|
| |
|
|
| fitz |
|
05/19/2014 01:20PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
You can use the $hlib/install.port script to create the needed system links for building from source. The bug in the current install script that causes the install to fail in a source-only system will be fixed for the next release and the README file instructions updated.
|
| |
|
|
| olebole |
|
05/19/2014 08:14PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
install.POST does not work either:
TXT Formatted Code new iraf root directory (/home/ole/Projects/2011/debian/iraf/2.16.1/src): default root image storage directory (/tmp): local unix commands directory (/usr/local/bin): install iraf for machine type linux
old iraf root = /home/ole/Projects/2011/debian/iraf/2.16.1/src, old imdir = /tmp
installing iraf at /home/ole/Projects/2011/debian/iraf/2.16.1/src, imdir=/tmp, lbindir=/usr/local/bin
proceed with installation? (yes):
chmod: Beim Setzen der Zugriffsrechte für »/tmp“: Die Operation ist nicht erlaubt
default root imdir is ok
set delete permission on /tmp
chmod: Beim Setzen der Zugriffsrechte für »/tmp“: Die Operation ist nicht erlaubt
set mode 0666 on magtape devices to permit tape allocation
chmod: No match.
iraf .login file is ok
mkiraf.csh is ok
libc/iraf.h is ok
cl.csh is ok
--------------- Check File Permissions ----------------
---------------- Check Symbolic Links -----------------
make symbolic link /usr/include/iraf.h -> /home/ole/Projects/2011/debian/iraf/2.16.1/src/unix/hlib/libc/iraf.h
ln: Die symbolische Verknüpfung »/usr/include/iraf.h“ konnte nicht angelegt werden: Keine Berechtigung
directory /usr/local/bin
/bin/ls: Zugriff auf cl nicht möglich: Datei oder Verzeichnis nicht gefunden
[...]
invoking "make linux64" after that produces a
TXT Formatted Code (util/mkarch linux64)
/home/ole/Projects/2011/debian/iraf/2.16.1/src//unix/hlib/setup.sh: Zeile 10: /iraf/iraf//unix/hlib/irafarch.sh: Datei oder Verzeichnis nicht gefunden
/home/ole/Projects/2011/debian/iraf/2.16.1/src//unix/hlib/setup.sh: Zeile 12: /iraf/iraf//unix/hlib/irafuser.sh: Datei oder Verzeichnis nicht gefunden
unix/hlib/irafarch.sh: Zeile 45: /iraf/iraf//unix/hlib/util.sh: Datei oder Verzeichnis nicht gefunden
unix/hlib/irafarch.sh: Zeile 236: ECHO: Kommando nicht gefunden.
Making architecture:
util/mkarch: Zeile 47: /iraf/iraf//util/mkclean: Datei oder Verzeichnis nicht gefunden
util/mkarch: Zeile 61: cd: /iraf/iraf/: Datei oder Verzeichnis nicht gefunden
Also, I think the second problem I wrote (that iraf.h was not found) does not have anything to do with the shell script, right?
Best
Ole
|
| |
|
|
| fitz |
|
05/19/2014 08:20PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Did you run the script as root or with 'sudo'? The /usr/include/iraf.h file is required for building the system from source since it is included by the iraf kernel code, mkpkg/xc, etc.
|
| |
|
|
| olebole |
|
05/19/2014 08:36PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Must this be installed *before* the system is going to be compiled?
And which one?
PHP Formatted Code find . -name iraf .h
./unix /bin .linux /iraf .h
./unix /bin .macintel /iraf .h
./unix /hlib /iraf .h
./unix /hlib /libc /iraf .h
./unix /bin .macosx /iraf .h
./unix /bin .linux64 /iraf .h
|
| |
|
|
| fitz |
|
05/19/2014 08:43PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Yes, before it is compiled. It needs to be a symlink to hlib$libc/iraf.h and is normally in /usr/include, but $HOME/.iraf/iraf.h should also work.
|
| |
|
|
| olebole |
|
05/20/2014 04:59AM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
This does not work, since unix/libc/iraf.h contains lines like
PHP Formatted Code #ifdef import_stdio
#ifndef D_stdio
#include "/iraf/iraf/unix/hlib/libc/stdio.h"
#endif
#undef import_stdio
#endif
and therefore these includes are not found.
|
| |
|
|
| fitz |
|
05/20/2014 08:01AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
The install script edits the iraf path in this file (and others, see the script for a list) so it is correct for the system. For the moment you could simply create a /iraf link pointing to your directory so the /iraf/iraf path is valid. Alternative, wait for the proper lunar phase and do a normal installation with full binaries, then a "make linux ; make src" to set the architecture links and remove all binaries .
|
| |
|
|
| olebole |
|
05/31/2014 02:56PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
OK, so I commented out the failure in the install script:
DIFF Formatted Code --- a/install
+++ b/install
[@@ -1089,13 +1089,6 @@
chmod 755 $file
fi
fi
- else
- if [ "$err_seen" == 0 ]; then
- DO_FAIL
- err_seen=1
- err_count=$(( err_count+1 ))
- fi
- MSG "File $i not found."
fi
done
if [ "$err_seen" == 0 ]; then
This makes the install script succeeding -- at least, somehow :-)
I still get this:
EXAMPLE Formatted Code $ ./install -i /tmp/iraf/imdir -b /tmp/iraf/bin -c /tmp/iraf/cache
[...]
Default root image storage directory (/home/ole/.iraf/imdir/): /tmp/iraf/imdir
Default root cache directory (/home/ole/.iraf/cache/): /tmp/iraf/cache
Local unix commands directory (/home/ole/.iraf/bin/): /tmp/iraf/bin
[...]
========================================================================
===================== Verifying System Settings ======================
========================================================================
Hostname = poch OS version = Linux 3.13.0-27-generic
Architecture = linux64 HSI arch = linux64
Old iraf root = /iraf/iraf New iraf root = /home/ole/Projects/2011/debian/iraf/2.16.1/iraf
Old imdir = /iraf/imdir New imdir = /tmp/iraf/imdir
Old cache = /iraf/cache New cache = /tmp/iraf/cache
Local bin dir = /home/ole/.iraf/bin
So, it does not take the command line parameters -i, -b, and -c as defaults, and even if I set the local bin dir manually, it is not set. Could this be corrected in the install script as well?
Also, there are some links in the tar file wrong which cause the compilation to fail:
EXAMPLE Formatted Code $ find . -type l -exec ls -l {} \;|fgrep /iraf/iraf
lrwxrwxrwx 1 ole ole 29 Okt 22 2013 ./sys/osb/i1mach.f -> /iraf/iraf/unix/hlib/i1mach.f
lrwxrwxrwx 1 ole ole 29 Okt 22 2013 ./sys/osb/r1mach.f -> /iraf/iraf/unix/hlib/r1mach.f
lrwxrwxrwx 1 ole ole 29 Okt 22 2013 ./sys/osb/d1mach.f -> /iraf/iraf/unix/hlib/d1mach.f
lrwxrwxrwx 1 ole ole 27 Okt 22 2013 ./sys/osb/bytmov.c -> /iraf/iraf/unix/as/bytmov.c
Could you change them to be relative?
However, even after these changes, it does not compile. I now stops after the compilation of bootlib:
LOG Formatted Code [...]
+ ranlib libboot.a
+ mv -f libboot.a ../../bin
+ echo ----------------------- GENERIC ------------------------
[...]
+ gcc -Wl,-Bsymbolic-functions -Wl,-z,relro -m64 generic.o lexyy.o chario.o yywrap.o /home/ole/Projects/2011/debian/iraf/2.16.1/iraf/unix/hlib/libboot.a /home/ole/Projects/2011/debian/iraf/2.16.1/iraf/unix/hlib/libos.a -o generic.e
gcc: error: /home/ole/Projects/2011/debian/iraf/2.16.1/iraf/unix/hlib/libboot.a: Datei oder Verzeichnis nicht gefunden
gcc: error: /home/ole/Projects/2011/debian/iraf/2.16.1/iraf/unix/hlib/libos.a: Datei oder Verzeichnis nicht gefunden
Any idea what happens here?
|
| |
|
|
| olebole |
|
06/02/2014 01:28PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Just a bit more...
If one types "help" at one of the prompts in the install script, the following happens:
TEXT Formatted Code ========================================================================
===================== Query for System Settings ======================
========================================================================
New iraf root directory (/home/oles/Projects/2011/debian/iraf/orig): help
*** The
*** file
*** 'local',
***
*** The
New iraf root directory (/home/oles/Projects/2011/debian/iraf/orig):
which is just the first word of each help line.
|
| |
|
|
| olebole |
|
06/02/2014 02:06PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
The missing parameter settings in the install script may be fixed with this patch:
PATCH Formatted Code --- a/install
+++ b/install
@@ -167,10 +167,10 @@ while [ -n "$1" ] ; do
;;
"-t"|"-term"|"--term") # set default terminal type.
- defterm=$2 ; shift
+ p_defterm=$2 ; shift
;;
"-b"|"-bindir"|"--bindir") # set local bin director
- bindir=$2 ; shift
+ p_lbin=$2 ; shift
;;
"-c"|"-cache"|"--cache") # set cache directory
p_cache=$2 ; shift
@@ -412,8 +412,11 @@ else
fi
fi
-
-iraf_prompt="yes"
+if [ "$p_iraf" ] ; then
+ iraf_prompt="no"
+else
+ iraf_prompt="yes"
+fi
while [ $iraf_prompt == "yes" ]; do
d_iraf=`ECHO $d_iraf | sed -e 's+/\(["]*\)$+\1+'`
@@ -477,7 +480,12 @@ if [ "$imdir" == "" ]; then
d_imdir="/tmp"
fi
- imdir_prompt="yes"
+ if [ "$p_imdir" ] ; then
+ imdir=$p_imdir
+ imdir_prompt="no"
+ else
+ imdir_prompt="yes"
+ fi
while [ "$imdir_prompt" == "yes" ]; do
imdir_prompt="no"
@@ -541,7 +549,12 @@ if [ "$cache" == "" ]; then
d_cache="/tmp"
fi
- cache_prompt="yes"
+ if [ "$p_cache" ] ; then
+ cache=$p_cache
+ cache_prompt="no"
+ else
+ cache_prompt="yes"
+ fi
while [ "$cache_prompt" == "yes" ]; do
cache_prompt="no"
@@ -603,7 +616,12 @@ if [ "$lbin" == "" ]; then
d_lbin="/usr/bin"
fi
- lbin_prompt="yes"
+ if [ "$p_lbin" ] ; then
+ lbin=$p_lbin
+ lbin_prompt="no"
+ else
+ lbin_prompt="yes"
+ fi
while [ "$lbin_prompt" == "yes" ]; do
lbin_prompt="no"
@@ -654,12 +672,15 @@ if [ "$lbin" == "" ]; then
fi
done
fi
-
+bindir=$lbin
# Prompt for the terminal to use in a private installation.
if (( $do_system==0 )); then
+ if [ "$p_defterm" ] ; then
+ myterm=$p_defterm
+ else
myterm="none"
BOLD_ON
ECHO "Terminal types: xgterm, xtermjh, xterm, etc."
@@ -674,6 +695,7 @@ if (( $do_system==0 )); then
if [ -z "$myterm" ]; then
myterm=$defterm
fi
+ fi
fi
It would also be nice if the install script would have a non-interactive mode which omits the final "yes" for a better use in scripts.
|
| |
|
|
| olebole |
|
06/02/2014 02:57PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Completely different part: to get the Fortran sources for rpp, one needs a ratfor compiler. There is one (public domain) included in several linux distributions, however, the Makefile in rpprat warns: A TOOLS compatible ratfor compiler is required to compile this. The original UNIX ratfor compiler may not do
the job.
What is a "TOOLS compatible ratfor compiler"? Is the PD one TOOLS compatible (at least, it is not an "original UNIX ratfor compiler")? If this one doesn't work, where can I find one?
Best regards
Ole
|
| |
|
|
| olebole |
|
06/02/2014 06:37PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Another point: The installation seems to require that the links to the newly created mkpkg.e, xc.e etc. are in the $path. This is not documented (the help just says "Ideally it should be a directory on the standard user $path", without describing that this is essential. Also, if there is already an IRAF installed (and the new one is still not in the PATH, or is in the path after the old ones), the wrong (old) binaries are used for the compilation.
It would be better if these links are (for compilation) installed in a temporary local directory.
BTW, I don't know if you are interested in such kind of problem reports. What would you recommend to proceed here?
|
| |
|
|
| fitz |
|
06/03/2014 05:03AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Omnibus reply to the last few posts:
Could you change them to be relative?
The files are checked out of the hlib$ directory at compile time by making a link and then deleted when complete. These are apparently examples of stray files from a failed compilation that weren't cleaned up and so the /iraf/iraf path is because of what's used here. Delete the symlinks and the compilation should checkout the files using your path.
However, even after these changes, it does not compile. I now stops after the compilation of bootlib:
:
gcc: error: /home/ole/Projects/2011/debian/iraf/2.16.1/iraf/unix/hlib/libboot.a: Datei oder Verzeichnis nicht gefunden
gcc: error: /home/ole/Projects/2011/debian/iraf/2.16.1/iraf/unix/hlib/libos.a: Datei oder Verzeichnis nicht gefunden
Any idea what happens here?
Did you delete the libboot.a and libos.a symlinks in hlib? Did the libraries compile correctly? Is the unix$bin symlink pointing to the right bin directory?
If one types "help" at one of the prompts in the install script, the following happens:
Change the hlib$util.sh script so the '$1' in the MSG/MSGN/ERRMSG procedures becomes a "$*' to print all the words in the arg.
The missing parameter settings in the install script may be fixed with this patch:
Thanks, I'll apply the patch and add an argument to avoid the final prompt
What is a "TOOLS compatible ratfor compiler"?
I believe this refers to the Kernighan&Plaugher "Software Tools" book implementation of RATFOR.
It would be better if these links are (for compilation) installed in a temporary local directory.
I'm not sure what you mean here, the $path would then just need to contain the temp local dir instead? You can have multiple versions installed where e.g. different 'mkpkg' links point to different versions but it is still up to you to set an environment that picks up one version first or else call the commands using the path to the explicit version. The install script should not be managing multiple versions.
|
| |
|
|
| olebole |
|
06/04/2014 12:20PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
If I try to rebuild unix/boot/generic/lexyy.c, the resulting generic.e crashes when building the sys/vops/ak/acht*.x files.
The file lexyy.c in the tarball is also much smaller than the one that is created by (f)lex: 12k vs. 54kbytes.
How can I create the lexyy.c from tok.l?
Similarly, in unix/boot/spp/xpp/, the xpp crashes if the "-l" option of flex is not used. The mkpkg.sh file does not contain the "-l" flag; however it seems to be used manually when the lexyy.c was created, since it defines YY_FLEX_LEX_COMPAT which shows that "flex -l" was used. Could you document that somewhere?
What about the other lex sources? Are they fine with flex?
|
| |
|
|
| fitz |
|
06/04/2014 05:34PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Most of the lexer code is old enough that it was originally compiled using the BSD lex which has some incompatibilities with the POSIX flex version. For things like XPP this was already fixed because it was modified recently, the GENERIC task wasn't addressed because the tok.l/lexyy.c hasn't been updated since 1989. I think the only other place lex files are used are in the CL/ECL/VOCL.
|
| |
|
|
| olebole |
|
06/04/2014 06:26PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
So this means that today we are already not able to really build IRAF from source? Not nice.
I am also still fiddling around with the ./install script, which seems to do the wrong thing: If I have an old IRAF installation somewhere (f.e. under /iraf/2.16), and my $iraf points there, and then I want to install a new one: If I then type ./install, it takes the $imdir from the old[/] installation and tries to search/replace this string in the new installation, which ofcourse will fail (in the pristine installation from tar it is still /iraf/iraf). So, after running /install, the scripts are unchanged.
Wouldn't it be better if the replacement was not in-place, but you had templates, like iraf.h.in which remains unchanged, but with the install script a iraf.h is created from that? Then the ./install script would not need this weird logic to find out the "old" imdir; it could just assume that it is the default.
|
| |
|
|
| fitz |
|
06/04/2014 06:36PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
So this means that today we are already not able to really build IRAF from source?
Not true, since the source that gets compiled is the 25 year old lexyy.c. If you change something (i.e. tok.l) and create a new lexyy.c then yes there is a problem to be fixed. The same is true for any other source change.
Feel free to fix it.
|
| |
|
|
| olebole |
|
06/04/2014 06:56PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Quote by: fitzSo this means that today we are already not able to really build IRAF from source?
Not true, since the source that gets compiled is the 25 year old lexyy.c. If you change something (i.e. tok.l) and create a new lexyy.c then yes there is a problem to be fixed. The same is true for any other source change.
Feel free to fix it.
It is on my Agenda, yes. What is this "generic.new", BTW?
lexyy.c is not source (Source means that it is the preferred file to edit) but it generated.
What about the ./install proposal? Would you change this? Shall I send you a patch for this? Where should I upload the patch to?
|
| |
|
|
| fitz |
|
06/04/2014 07:04PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
It is on my Agenda, yes. What is this "generic.new", BTW?
Hmmm, looks like I took a swipe at this last year and never cleaned up. You can delete it.
lexyy.c is not source (Source means that it is the preferred file to edit) but it generated.
Did you edit the file?
What about the ./install proposal? Would you change this? Shall I send you a patch for this? Where should I upload the patch to?
I'll have a look at it (but no promises). Just email it to me (fitz-at-iraf.net)
|
| |
|
|
| fitz |
|
06/05/2014 02:17AM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
I am also still fiddling around with the ./install script, which seems to do the wrong thing: If I have an old IRAF installation somewhere (f.e. under /iraf/2.16), and my $iraf points there, and then I want to install a new one: If I then type ./install, it takes the $imdir from the old[/] installation and tries to search/replace this string in the new installation, which ofcourse will fail (in the pristine installation from tar it is still /iraf/iraf). So, after running /install, the scripts are unchanged.
I just caught this after re-reading it: If you set a $iraf at all you MUST set it to the iraf root you are trying to install, regardless of whether there is another version on the machine. By having your $iraf point at your old iraf system, but running the new install script, all you're doing is running the new install script on the old directory and any edits of the iraf path have no effect because you haven't changed anything.
|
| |
|
|
| olebole |
|
06/05/2014 07:21AM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Quote by: fitzlexyy.c is not source (Source means that it is the preferred file to edit) but it generated. Did you edit the file?
The idea of Open Source is that we make it easy for others to change the software, which obviously meany that the software can be rebuilt from the (changeable) source. This is not the case if it needs some old, no longer available, lex from 25 years ago.
IRAF uses lots of open source, and it is legally bound to it since it must be redistributable under GPL (because it is linked to GPL software: readline and slalib), so it should follow its ideas.
So, it is on my (medium-term) agenda to allow recreation of the lexyy.c.
If you set a $iraf at all you MUST set it to the iraf root you are trying to install, regardless of whether there is another version on the machine. By having your $iraf point at your old iraf system, but running the new install script, all you're doing is running the new install script on the old directory and any edits of the iraf path have no effect because you haven't changed anything.
This is weird, isn't it? Imagine, someone has a personal IRAF installation, and he wants to try out the new one. He would destroy the old setting and also not get the new one running. And there is no way to get the old setting back unless he remembers it or it was the default).
Do you have any use case that the install script from a new IRAF tarball should change an old installation?
I'll have a look at it (but no promises). Just email it to me (fitz-at-iraf.net)
I'll prepare it at the weekend.
Best
Ole
|
| |
|
|
| fitz |
|
06/05/2014 01:45PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
This is not the case if it needs some old, no longer available, lex from 25 years ago.
If you change the lexer file then you must also fix the problem with flex incompatibility, GPL doesn't mean I am "legally bound" to do it for you in case you might change it in the future.
This is weird, isn't it? Imagine, someone has a personal IRAF installation, and he wants to try out the new one. He would destroy the old setting and also not get the new one running. And there is no way to get the old setting back unless he remembers it or it was the default).
It is not the install scripts job to manage other installations, it is the user's responsibility to make a backup of their $HOME/.iraf dir, set $iraf appropriately and/or reinstall the old version so the /usr/local/bin/cl link points back to the old version when they are done experimenting.
The reason for the /iraf/iraf path is that you can have a single installed path and then simply change versions by changing the /iraf/iraf link to point to /iraf/iraf_new or /iraf/iraf_old without rerunning the install script, or set a single $iraf to choose either runtime system. What's weird is insisting on /usr/share where multiple versions aren't an option at all.
Do you have any use case that the install script from a new IRAF tarball should change an old installation?
No, but my point is that it was a user error to set the wrong $iraf in the first place.
|
| |
|
|
| olebole |
|
06/05/2014 02:47PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Do you have any use case that the install script from a new IRAF tarball should change an old installation?
No, but my point is that it was a user error to set the wrong $iraf in the first place.
Sorry, but it is just a bug if the install script of a new version touches an old installation. There is no reason why it should do this.
As a user I expect that if I run "install", it changes the files of the package where the script belongs to, not the one that is already installed (if I would want to change that one, I would use the "install" script of the old one), regardless whether $iraf is set or not.
Why does the install script use $iraf at all?
|
| |
|
|
| fitz |
|
06/05/2014 03:04PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Why does the install script use $iraf at all?
It uses it if you set it, otherwise it defines $iraf based on the location of the install script (the behavior you describe). If you set $iraf, for whatever reason, then that value will be used whether it is from the environment or a command-line option to the script. Perhaps a warning is in order if the $iraf doesn't match, however you'd have to account for symlinks in the path to be sure the $iraf and $cwd were actually different.
If there were no options to override the values I'm sure we'd be having a different conversation.
|
| |
|
|
| olebole |
|
06/05/2014 03:15PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
But why does it use a pre-set $iraf?
My case may serve as an example here: I have two IRAF trees, one for Debian, and one for other stuff. First, I did something in the Debian tree (without setting $iraf at all), later I changed to the other tree to do something else (fixing your install script  )
After the work on the Debian tree, the install script has set my $iraf variable, without even notifying me, and when I then started to run ./install, it modified the Debian tree instead of the current one. This is just not expected behaviour. I do not expect that a script modifies my login (at least if the program is finally not installed), and I also not expect that the new ./install script moves over to the other installation (independently of whether $iraf was set or not).
So, my proposal is: ./install should always change its own tree, regardless of whether the $iraf variable set to somewhere else.
|
| |
|
|
| fitz |
|
06/05/2014 04:41PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
But why does it use a pre-set $iraf?
Strictly speaking, it doesn't. If you did a personal install of v2.16.1 then your .cshrc/.bashrc files were modified to do an iraf environment setup (i.e. $iraf et al) since this is what most users will need in their single-installation systems. If you don't want to do that, then do a system install (i.e. "./install --system") as root and your environment files are left alone and when you run the install script the next time there is no pre-set $iraf.
My case may serve as an example here: I have two IRAF trees, one for Debian, and one for other stuff. First, I did something in the Debian tree (without setting $iraf at all), later I changed to the other tree to do something else .....
The install script not only modifies paths in the files in the iraf tree, it creates command links using the $iraf path to point to e.g. the CL startup script. Your case of multiple versions is highly atypical among users but is also the reason for allowing the environment to define which version is used. In your case the problem is in using the personal install and rerunning the install script to switch versions without accounting for the environment defs. Again, the /iraf/iraf symlink trick is all you need: Run a system install with /iraf/iraf as the $iraf path, then to switch versions simply repoint the link and all the commands and paths are still valid for either version. You could extend this idea to a $HOME/.iraf symlink that manages dual personal installs as well.
So, my proposal is: ./install should always change its own tree, regardless of whether the $iraf variable set to somewhere else.
Then simply comment out the first if-clause of the install script and set iraf in the script in your copy. One use case for why allowing $iraf to override is in creating paths with a specific value, e.g. to have a /local/iraf path for all user machines getting their software from a central department NFS mount. Whether you intended/expected it or not, the script used the $iraf value it was told to use.
|
| |
|
|
| olebole |
|
06/06/2014 02:16PM
|
|
|
Status: offline
Registered: 05/01/2014
Posts: 103
|
Hi Fitz,
I am still looking through the install script. One of the problems that I see here is that is always changes the user environment, which is quite bad is someone just wants to experiment with a new version.
One of the reason it changes the environment seems to be the compilation -- it links the iraf.h there, and the compilation then includes $(HOME).iraf/include. Wouldn't it be better if the iraf.h would be linked to $iraf/include/iraf.h? If you would then do a link $iraf/include/iraf/ --\$this->_split2($m[0]) $iraf/unix/hlib/libc/, one could get rid of all the absolute paths in iraf.h and just replace them once and forever with
C Formatted Code #ifdef import_libc
#ifndef D_libc
#include
#endif
#undef import_libc
#endifThis would solve one of the ugliest annoyances that the iraf.h file needs to be patched when the package gets a new root. Then, a user woould need to use "-I$iraf/include" (instead of "-I$HOME/.iraf/") if a source file needs to include the header. And the compilation does not need to setup files outside of $iraf. A system installation then could link the /usr/include/iraf.h --\$this->_split2($m[0]) $iraf/unix/hlib/libc/iraf.h (as it is now), and /usr/include/iraf/ --\$this->_split2($m[0]) $iraf/unix/hlib/libc/ .
In iraf.h, there are also three runtime definitions that are used by shell scripts (unix/hlib/sysinfo) and C source (zgtenv.c):
C Formatted Code #define HOST $iraf/unix
#define IRAF $iraf
#define TMP $tmp
They could be replaced by
SHELL Formatted Code HOST=$(dirname $(dirname $(dirname $(readlink -f ~/.iraf/iraf.h))))
IRAF=$(dirname $HOST)
TMP=$TMPDIR # This is POSIX and similar in unix/os/zgtenv.c. This also has the advantage that there is no need to patch iraf.h when the the IRAF tree is moved to somewhere else (just set the link accordingly). This would also allow a setup like in my institute, where I have an IRAF installation at /work1/ole/iraf/, wich is visible on another computer as /net/work1/ole/iraf/ -- in the moment I could not re-use the installation for the other computer since the paths are hardcoded in iraf.h.
Any comments so far?
(I would even prefer to rename all the header files to avoid name clashes with the standard header: libc.h -\$this->_split2($m[0]) iraf-libc.h, alloc.h -\$this->_split2($m[0]) iraf-alloc.h etc., and include them directly in iraf.h with "#include
|
| |
|
|
| fitz |
|
06/06/2014 02:25PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Your proposed changes completely break IRAF networking which relies on finding a path in , not a runtime environment. See os$zfioks.c and sys$ki. And no, we aren't going to now go off and change those in a major way to accomodate iraf.h changes.
|
| |
|
|
New Topic
Post Reply
Quote
