iraf.net

Could you be a bit more verbose here? What exactly would break then?

... and: this were three proposals:

1. create a link $iraf/include/iraf.h --\$this->_split2($m[0]) $iraf/unix/hlib/libc/iraf.h and use "-I$iraf/include" instead of "-I$HOME/.iraf" in compilation
2. create a link $iraf/include/iraf --\$this->_split2($m[0]) $iraf/unix/hlib/libc/ and replace the #include "/iraf/iraf/..." lines by "#include " in iraf.h
3. replace the IRAF, HOST, and TMP dirs in iraf.h by another mechanism.

You argued against the last proposal, right? Independent whether we get a solution there, what about the other two?

A comment in sys/ki/irafks.xs is:which means that they use unix/os/zgtenv.c. This file can be simply changed, as described above.

See sys$ki/README for a description of IRAF networking. Basically the irafks.e process that is started remotely needs to know where iraf is installed to initialize the process and uses to get the IRAF/HOST/TMP paths. What you're suggesting (in some sort of shell usage in C code I don't follow) is that everything be based on a $iraf value in the environment, but that then now requires users to define $iraf just to use the system (iraf networking or not). Or, you're suggesting we read the link on the iraf.h file to determine the path which is an unnecesary complication.




Sounds reasonable, the $HOME/.iraf link is still required for the reasons above. I did notice that the zgtenv.c code still uses the old $HOME/.iraf.h which will be fixed.




I think the PHP cut off your code here but I think you're suggesting
"#include <iraf/something.h>" ? I'm not sure what you're saving here
since the file has to be edited by the install script anyway.




Not gonna happen.

This is not more complicated than parsing the file.
Great.
I meant that, yes.
If the file needs to be edited remains questionable
However, even in this case it would be good: for packaging, IRAF will be compiled on a place different from its installation place. In the moment, I would need to patch the file twice; reducing this would make the build simpler. In this case, one would not need to edit the files before compilation.
Why not? If this change is contributed by the community?

I'm slowly starting to convince myself this might work, except for the definition of 'tmp' (not everything is posix and not everything posix handles it the same way, that and their is frequent mixing of "/tmp" and "tmp$" in scripts the becomes an issue unless we just hardwire /tmp).

I'll look at it for the next release. (That is not just a deflection, but I really can't have whatever you're working on every day become what I'm working on that day).

Hi Fitz,

could you explain a bit the multi-arch structure of IRAF?

What is the reason for the links of the libraries like unix/hlib/libboot.a -\$this->_split2($m[0]) ../bin/libboot.a or lib/libsys.a -\$this->_split2($m[0]) ../bin/libsys.a? And what are the links bin-\$this->_split2($m[0])bin.bin.$MACH etc. for? If one would adjust the paths within IRAF, wouldn't it be possible to put everything under bin.$MACH only and remove the links? What would break then?

And what are the IB.LNUX.x86 and IRAF.NET files for? They seem to be created during tar file creation. What is their use?

Best

Ole

One more question here: IRAF sometimes uses MACH, sometimes IRAFARCH. Is there a difference between them? When should one use which?

These were simple conveniences because the unix$boot build scripts put the binaries to hlib$ and during a port/build the system architecture would point thes (because they went to '../bin/') to the right place.



I don't know what you mean here. Specific examples, please.



Using a common 'bin.$IRAFARCH' would be better now (see below).



These are simple tag files to identify the tar file when we used the as/ib/nb scheme rather than the simpler one-tarball method used now.



The difference was intreoduced when a single hardware system coould support multiple OS types, e.g. on DEC Utlrix running unix/vms or on x86 running solaris/freebsd/linux/other. This differentiation is probably no longer required but hasn't been a priority to clean up either. However, for your plans this may be an issue where IRAFARCH=linux but MACH could be x86/s390/arm/whatever.

I'm also having problems getting 2.16.1 to build. I'm doing my work in a public github account, https://github.com/steelewool/iraf. For right now, my current problem is that I'm unable to build libVO.a since it appears that the files that should be in vendor/voclient/libvo are missing. Does anyone know where I might find the latest 2.16.1 version of these files?

If anyone want to take a look at my current progress feel free. My son and I are posting issues so we can track our progress.

---

Rob Steele (Robert.D.Steele@jpl.nasa.gov)