#22110 closed submission (fixed)
libnova portfile submission
Reported by: | jtomshine@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.8.1 |
Keywords: | Cc: | ||
Port: | libnova |
Description
The following portfile is for "libnova". It is a necessary prerequisite for "indi" -- a telescope & astronomical instrument control package that I intend to make into a portfile next. Relevent pages are here:
http://libnova.sourceforge.net
and here:
Attachments (1)
Change History (7)
Changed 15 years ago by jtomshine@…
comment:1 Changed 15 years ago by tobypeterson
comment:2 Changed 15 years ago by tobypeterson
cleaned up whitespace, committed r59526 without the post-destroot stuff
Are you trying to compile something against it that is using "#include <earth.h>" ? Just use -I${prefix}/include/libnova if that's the case. Otherwise I see nothing wrong with the header files; the examples included with libnova build without issues.
comment:3 Changed 15 years ago by jtomshine@…
Whomever wrote the original include files did it in such a way that they don't properly reference one-another. E.g.:
libnova.h contains: #include <libnova/earth.h>
even though libnova.h and earth.h are in the same directory (/opt/local/includes/libnova/). Subsequent attempts to include these files when building the "indi" package (not yet a macport) fail due to the reference issue. Although my first instinct was to fix the problem directly by removing the "libnova/" bit from all the includes, this prevented the libnova package itself from compiling at all.
Rather than an extensive series of patches, it seemed that the symlinks solution fixed the reference problem without breaking anything else. Additionally, it's an approach used by some other packages (e.g., libpng, on a slightly less extensive scale).
Given the relatively small audience that this package will likely have, I can't see any harm in the symlink approach, even if it is "lame".
comment:4 Changed 15 years ago by tobypeterson
Resolution: | → fixed |
---|---|
Status: | new → closed |
That style of include should work fine as long as -I${prefix}/include is specified. #includes are not (necessarily, or even usually) relative paths
Closing this - I vehemently disagree with the strategy of placing a bunch of symlinks in ${prefix}/include, particularly since it does not appear to be necessary.
comment:5 follow-up: 6 Changed 15 years ago by tobypeterson
Just checked the libindi0 source - it's using #include <libnova.h>
I'd argue that they're doing it wrong, but this style of include works fine if you do -I${prefix}/include -I${prefix}/include/libnova
... no need for the symlinks
comment:6 Changed 15 years ago by jtomshine@…
Replying to toby@…:
Just checked the libindi0 source - it's using
#include <libnova.h>
I'd argue that they're doing it wrong, but this style of include works fine if you do
-I${prefix}/include -I${prefix}/include/libnova
... no need for the symlinks
I looked into it a bit more closely & now I just use a regular expression to change the includes in the sources for the package that relies on libnova (indi). This works well, is probably more canonical, and avoids the symlinks. When the indi port has been finished, I'll submit that too.
Thanks for the advice by the way -- I'd prefer to adhere to good style guidelines as much as possible.
-Jon
"master_sites sourceforge" will suffice
I don't understand the post-destroot phase - littering /opt/local/include with a bunch of symlinks is pretty lame. Could you go into more detail about your reasoning there?