Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#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:

http://www.indilib.org

Attachments (1)

Portfile (3.9 KB) - added by jtomshine@… 14 years ago.

Download all attachments as: .zip

Change History (7)

Changed 14 years ago by jtomshine@…

Attachment: Portfile added

comment:1 Changed 14 years ago by tobypeterson

"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?

comment:2 Changed 14 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 14 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 14 years ago by tobypeterson

Resolution: fixed
Status: newclosed

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 Changed 14 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 in reply to:  5 Changed 14 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

Note: See TracTickets for help on using tickets.