new port -- "indi" -- telescope control software

[jtomshine@…]

"indi" (Instrument-Neutral-Distributed-Interface, ​http://www.indilib.org) is a protocol designed to support control, automation, data aquisition, and exchange among hardware devices and software frontends. It serves as a communication layer for the control of automated telescopes through astronomical software such as kstars, xephem, etc., which are already available as macports.

[jtomshine@…]

Replying to jtomshine@…:

"indi" (Instrument-Neutral-Distributed-Interface, ​http://www.indilib.org) is a protocol designed to support control, automation, data aquisition, and exchange among hardware devices and software frontends. It serves as a communication layer for the control of automated telescopes through astronomical software such as kstars, xephem, etc., which are already available as macports.

...just curious if there is anything that I should change or add?

[jtomshine@…]

Hello to the void. I'm not sure if this note will be seen by anyone, but I submitted this port a few weeks ago & haven't heard anything back yet. After a week and a half or so, I resubmitted it, but the resubmission was immediately closed -- I was chastised for the duplicate and assured that it was simply a matter of waiting in the queue. Perhaps that's true, but I'm just posting this note as a "bump" to show that there's still someone watching this submission and waiting...

-Jon

Replying to jtomshine@…:

Replying to jtomshine@…:

"indi" (Instrument-Neutral-Distributed-Interface, ​http://www.indilib.org) is a protocol designed to support control, automation, data aquisition, and exchange among hardware devices and software frontends. It serves as a communication layer for the control of automated telescopes through astronomical software such as kstars, xephem, etc., which are already available as macports.

...just curious if there is anything that I should change or add?

[blb@…]

Updated Portfile

[blb@…]

I've attached an updated Portfile which does the following:

• downloads the distfile as it is originally named, and no longer hardcodes the version anywhere (other than version itself, of course)
• removed the pre-configure stage by instead pointing NOVA_INCLUDE_DIR to the full libnova include path
• set CMAKE_INSTALL_PREFIX during destroot so all files are properly installed into the destroot, as the original Portfile installed everything directly to ${prefix} which is bad

If it looks good, I'll go ahead and commit.

[jtomshine@…]

The modified looks okay, but there are a few issues. First, and least significant, the symbolic links that are created by the application's install process no longer uninstall cleanly. Whether this is a major flaw or not, I'm not sure, and the symlinks aren't really even necessary, so they could just be removed altogether.

More significant (and probably due to the removal of the pre-configure stage) is the apparent inability of the compiler to properly include files from libnova. With the updated port, "port -d install" produces the following tell-tale lines:

-- Performing Test NOVA_FUNCTION_COMPILE
-- Performing Test NOVA_FUNCTION_COMPILE - Failed

I'm fairly sure that this broke due to the removal of the pre-configure stage, since solving this problem is the reason why I put that there in the first place.

-Jon

[blb@…]

Replying to jtomshine@…:

The modified looks okay, but there are a few issues. First, and least significant, the symbolic links that are created by the application's install process no longer uninstall cleanly. Whether this is a major flaw or not, I'm not sure, and the symlinks aren't really even necessary, so they could just be removed altogether.

Which symlinks are these? I only see the dylib-related ones in ${prefix}/lib and they look okay.

More significant (and probably due to the removal of the pre-configure stage) is the apparent inability of the compiler to properly include files from libnova. With the updated port, "port -d install" produces the following tell-tale lines:

-- Performing Test NOVA_FUNCTION_COMPILE -- Performing Test NOVA_FUNCTION_COMPILE - Failed

That seems to work here, did you already have indi installed when you tried this? Perhaps it has issues with that...

I'm fairly sure that this broke due to the removal of the pre-configure stage, since solving this problem is the reason why I put that there in the first place.

The use of -DNOVA_INCLUDE_DIR=${prefix}/include/libnova should solve the same issue, and at least appears to do so for me. Running nm against one of the binaries (indi_lx200generic) shows a number of libnova symbols in it (eg, _ln_get_julian_day) so it seems to be compiling and linking to it properly.

-Jon

[jtomshine@…]

Well, if you aren't getting the "NOVA_FUNCTION_COMPILE - Failed" message when you install with the "-v" option (and you get an executable called "indi_temma" in /opt/local/bin or wherever the rest of the executables go), then it must be working okay. Not sure what the issue is on my end, but then again, I'm *very* new to portfile development (this is only #2 for me). Go ahead and commit it.

Hopefully this new port will get some use though, as two other ports (kstars in the kdeedu port and the xephem port) both have support for the indi interface.

[blb@…]

When building, I see

...
-- Performing Test NOVA_FUNCTION_COMPILE
-- Performing Test NOVA_FUNCTION_COMPILE - Success
-- Found NOVA: /mp/lib/libnova.a
...

All the files installed in bin:

-rwxr-xr-x  1 blb  admin   93560 Nov 13 00:46 indi_celestron_gps
-rwxr-xr-x  1 blb  admin   63304 Nov 13 00:46 indi_eval
-rwxr-xr-x  1 blb  admin   53832 Nov 13 00:46 indi_getprop
-rwxr-xr-x  1 blb  admin   87960 Nov 13 00:46 indi_intelliscope
-rwxr-xr-x  1 blb  admin  108640 Nov 13 00:46 indi_lx200basic
-rwxr-xr-x  1 blb  admin  222104 Nov 13 00:46 indi_lx200generic
-rwxr-xr-x  1 blb  admin   98544 Nov 13 00:46 indi_orion_atlas
-rwxr-xr-x  1 blb  admin   91176 Nov 13 00:46 indi_robofocus
-rwxr-xr-x  1 blb  admin   49424 Nov 13 00:46 indi_setprop
-rwxr-xr-x  1 blb  admin   87960 Nov 13 00:46 indi_skycommander
-rwxr-xr-x  1 blb  admin  107216 Nov 13 00:46 indi_temma
-rwxr-xr-x  1 blb  admin   73584 Nov 13 00:46 indi_trutech_wheel
-rwxr-xr-x  1 blb  admin   43328 Nov 13 00:46 indiserver

When you tried my Portfile, did you already have your original indi installed? Maybe they are conflicting?

The generated CMakeCache.txt file definitely is recording that it found it properly:

NOVA_INCLUDE_DIR:PATH=/mp/include/libnova

(My prefix is /mp instead of /opt/local)

Looking at cmake_modules/FindNova.cmake, it should find the file in /opt/local/include/libnova as libnova.h, nothing odd/special there that I can see.

[jtomshine@…]

It appears to be working perfectly for you, so I'm not sure what's wrong on my end. I'll continue to play with it -- see if I can make your Portfile work on my system. Are you sure that the Portfile you posted is exactly the same as the one you're using (and having success with)?

I've tried & retried the installation: making doubly- and triply-sure that my earlier version was uninstalled and even uninstalling & reinstalling the libnova port, and for the life of me I can't figure out what's wrong...

In any case, even if it doesn't find libnova, it's not fatal -- it just means that certain executables won't be produced, and a slightly smaller set of telescopes will be supported as a result.

[blb@…]

Replying to jtomshine@…:

It appears to be working perfectly for you, so I'm not sure what's wrong on my end. I'll continue to play with it -- see if I can make your Portfile work on my system. Are you sure that the Portfile you posted is exactly the same as the one you're using (and having success with)?

Yup, 'tis identical.

I've tried & retried the installation: making doubly- and triply-sure that my earlier version was uninstalled and even uninstalling & reinstalling the libnova port, and for the life of me I can't figure out what's wrong...

Check to make sure you don't have /opt/local/include/libindi and /opt/local/lib/libindi* from prior installs.

In any case, even if it doesn't find libnova, it's not fatal -- it just means that certain executables won't be produced, and a slightly smaller set of telescopes will be supported as a result.

I can commit as is, I imagine if someone else does run into the same issue that would at least help track down why it works for me but not for you...

[jtomshine@…]

Yes, I've searched backwards & forwards for files left over from prior installs, and that isn't it (as far as I can tell). My installation of macports is pretty plain-vanilla at the moment too, since I just upgraded to 10.6 quite recently & started from scratch.

I'd just go ahead & commit for the moment. With any luck, a few more reports might break the impasse. ...though the failure is so subtle that it might not be noticed by many users, and this port probably won't have a huge amount of traffic anyway.

Thanks, -Jon

[blb@…]

indi added in r60619, thanks. Now we just wait and see what happens...

[jtomshine@…]

Just a quick followup. I was able to get your version of the port (the one that's live now) to work properly by specifying alternate compilers. Using the copies of gcc43 and gcc44 installed through macports seems to work, but using the default version that came with xcode doesn't. Strangeness...

I suspect that there might be something fishy with libnova -- I tried compiling some of their example code ( ​http://libnova.sourceforge.net/examples.html ), and it displays odd output -- looks like some kind of pointer problem, but I didn't spend much time looking at it.

[blb@…]

You mean like (from lunar.c):

Rise
 Year    : -5884200
 Month   : -8
 Day     : -14
 Hours   : -2147483648
 Minutes : -2147483648
 Seconds : 4702720378736150528.000000

[jtomshine@…]

Yes, I get exactly the same sort of nonsense.

-Jon

Replying to blb@…:

You mean like (from lunar.c):

Rise
 Year    : -5884200
 Month   : -8
 Day     : -14
 Hours   : -2147483648
 Minutes : -2147483648
 Seconds : 4702720378736150528.000000