~/.iraf/iraf.h vs. ~/.iraf.h
gelato wrote on Nov 29, 2010
I've been looking with interest at some of the packaging/build changes in the 2.15 release. While I wholeheartedly applaud the goal of freeing oneself of the need to install iraf.h in /usr/include, I've stumbled upon a few apparent inconsistencies in the present state of affairs.
irafuser.csh now adds the directory $HOME/.iraf/ to the include search path. As indicated in the comment, the main use case for this is to allow a user to supply an own $HOME/.iraf/iraf.h .
On the other hand, unix/os/zgtenv.c was modified to use not $HOME/.iraf/iraf.h but $HOME/.iraf.h . I wonder what's the reasoning behind this. If the long-term goal is to split the two functions of iraf.h (as an include file for C source code and an input file for zgtenv), why keep a .h suffix for the latter function? And if it isn't, why not continue to use the same file (preferably in the .iraf subdirectory, to reduce clutter)?
On a related note, I'll point out that while the HSI_*F variables in irafuser.csh have been augmented, the XFLAGS and XVFLAGS settings elsewhere have not. As a result, when attempting to build IRAF from source the initial bootstrap will use $HOME/.iraf/iraf.h if it exists, but many subsequent builds will not. This causes compilation failures (on a system without /usr/include/iraf.h) for a few routines in libvops (at least; I've yet to look further than that).
While I'm at it, I'll opine that libc/libc.h should be added to the PATHFILES list in the install script since it contains a couple of #include "/iraf/iraf/... directives.
irafuser.csh now adds the directory $HOME/.iraf/ to the include search path. As indicated in the comment, the main use case for this is to allow a user to supply an own $HOME/.iraf/iraf.h .
On the other hand, unix/os/zgtenv.c was modified to use not $HOME/.iraf/iraf.h but $HOME/.iraf.h . I wonder what's the reasoning behind this. If the long-term goal is to split the two functions of iraf.h (as an include file for C source code and an input file for zgtenv), why keep a .h suffix for the latter function? And if it isn't, why not continue to use the same file (preferably in the .iraf subdirectory, to reduce clutter)?
On a related note, I'll point out that while the HSI_*F variables in irafuser.csh have been augmented, the XFLAGS and XVFLAGS settings elsewhere have not. As a result, when attempting to build IRAF from source the initial bootstrap will use $HOME/.iraf/iraf.h if it exists, but many subsequent builds will not. This causes compilation failures (on a system without /usr/include/iraf.h) for a few routines in libvops (at least; I've yet to look further than that).
While I'm at it, I'll opine that libc/libc.h should be added to the PATHFILES list in the install script since it contains a couple of #include "/iraf/iraf/... directives.
Mike Fitzpatrick wrote on Nov 29, 2010
I've been looking with interest at some of the packaging/build changes in the 2.15 release. While I wholeheartedly applaud the goal of freeing oneself of the need to install iraf.h in /usr/include, I've stumbled upon a few apparent inconsistencies in the present state of affairs. .......
The reason this wasn't mentioned in (or, at least, should have been removed from) the release documentation is that the feature isn't complete, I don't expect it to work at the moment. The idea behind perhaps having a separate $HOME/.iraf directory is that it could not only be used for an iraf.h file, but also for a "generic" login.cl/uparm that would remove the need for a 'mkiraf'. For the moment you still need to run the install script and have a /usr/local/iraf.h on the system, I expect this feature to be available in the 2.15.1 patch.
On a related note, I'll point out that while the HSI_*F variables in irafuser.csh have been augmented, the XFLAGS and XVFLAGS settings elsewhere have not.
The HSI flags are used to bootstrap the system, e.g. to build the iraf kernel using the host CC command before we have XC/MKPKG built. The XFLAGS don't need to be augmented because flags like '-m64' are added by XC automatically.
While I'm at it, I'll opine that libc/libc.h should be added to the PATHFILES list in the install script since it contains a couple of #include "/iraf/iraf/... directives.
Good point, I'll add it to the list of files where $iraf is edited.
Last post on Nov 29, 2010