iraf-v216 · Code · Issues (50) · Pull requests (81)
iraf.net Issue #7
Old references to /iraf/iraf in libc.h
closed steelewool opened this issue on 2017-04-27 · 6 comments
steelewool commented on 2017-04-27
These two references look like they old and should be replaced. Does anyone have any thoughts on how the .h files should actually be referenced?
steele@steele-VirtualBox:~/git/iraf-v216/unix/hlib/libc$ grep “iraf/iraf” *
libc.h:#include “/iraf/iraf/unix/bin/f2c.h”
libc.h:#include “/iraf/iraf/unix/hlib/libc/vosproto.h”
steelewool commented on 2017-05-01
Just to clarify based on some e-mails and posts (@zcsteele @iraf @joequant @olebole) this problem as I see was the fact that source files were referencing ‘/iraf/iraf’ in include statements. I would think this is something that can’t be fixed by the .install file or by some use of CFLAGS. Even relative references to the intended source file would be better. Let me know what people think of a good long term solution and I’ll implement that in my cleanup-/iraf/iraf branch. So in summary I see this as a source code problem/error.
RobSteele49 commented on 2017-05-02
I’m pretty sure, but maybe @iraf or @zcsteele or @joequant or @olebole) can confirm if the make system (./install make liinux64 make sysgen) at some point is modifying source files and changing ‘/iraf/iraf’ to something else (/home/steele/git/iraf-v216) during the build process. If this is the case it seems that this should be documented.
olebole commented on 2017-05-03
IMO it is ugly to modify existing files. The usual way is to have templates like libc.h.in with some placeholder in it, and to generate the final files (libc.h) from there.
But for the moment, it is more important to get the package built as intended. From there we can think about improvements.
olebole commented on 2017-05-03
Moving part of the discussion from #25:
Something like an “iraf.h.in” template file is indeed more modern but there is no PR to implement this nor is there any suggestion of how a full binary distribution where /iraf/iraf is the default path would be handled by the install script.
As I wrote: I think this should be done later only. This is however one of the many points where I ask myself why IRAF on any decision they had to make, they went the non-standard way which makes it problematic later.
joequant commented on 2017-05-03
I think that the approach that I took was to just have libc.h include
iraf.h and then change the compile files so that the directory of iraf.h
set up in the compile command.
On Wed, May 3, 2017 at 2:41 PM, Ole Streicher wrote:
[…]
steelewool commented on 2017-05-14
As we now have PRs that allow a build I’m going to close this issue.
Closed on 2017-05-14