Missing "get_bin.h" about jpl_eph HOT 10 OPEN

Hi Pedro,

You're right. I see that I've added a dependency here on the lunar library of basic astronomical functions. You have to download that, make and make install it to get at get_bin.h.

Alternatively, I am pretty sure you could download get_bin.h to the jpl_eph directory and go ahead and compile everything. And I could then just have get_bin.h be distributed with jpl_eph, and not incur a dependency in a project that is currently just about free of them... I'll see if I can arrange that.

Thanks!

from jpl_eph.

Cool! I did just that: downloaded the get_bin.h from lunar and compiled.

Thanks!

• Pedro.

from jpl_eph.

I was going to open an issue about this, but see it already exists.
I was following these instructions https://projectpluto.com/find_sou.htm
and found the jpleph.cpp:65:21: fatal error: get_bin.h: No such file or directory error on the make libjpl.a step. I saw that get_bin.h was in the lunar directory, so I tried to skip ahead to the lunar section, first doing make then make integrat, which failed with this warning:

/usr/bin/ld: cannot find -ljpl
collect2: error: ld returned 1 exit status
make: *** [integrat] Error 1`

I did not try to proceed to the make install step; instead I just copied the get_bin.h from the lunar directory to the jpl_eph directory and then followed the instructions in order again from make libjpl.a and everything appeared to work :-).
In conclusion: Maybe you should copy get_bin.h to this repository?

from jpl_eph.

You can actually just do make and make install in the lunar project. It'll complain about the absence of integrat, but that's essentially a cosmetic error (one I should fix, though; it's not at all obvious that it is just cosmetic!)

from jpl_eph.

Hello,
there is a circular dependency between lunar and jpl_eph. When compiling lunar first, I get:

cc -g -O2 -fdebug-prefix-map=/home/moeller/git/astro-team/pluto-lunar=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -I/usr/include/pluto -c alt_az.cpp
alt_az.cpp:22:10: fatal error: watdefs.h: No such file or directory
 #include "watdefs.h"
          ^~~~~~~~~~~
compilation terminated.
make[1]: *** [makefile:104: alt_az.o] Error 1

Could you please move the get_bin.h for me to upload a clean (patch free) release to Debian?
Cheers,
Steffen

Edit: No urgency, have uploaded with that "copy get_bin.h" patch.

from jpl_eph.

@smoe - that seems quite odd... both watdefs.h and alt_az.cpp are part of lunar. You should have gotten them both at the same time, in the same directory.

Is it possible watdefs.h accidentally got moved or deleted? A git pull ought to recover it...

from jpl_eph.

Ooops. My bad. It is both in jpl_eph (https://github.com/Bill-Gray/jpl_eph/blob/master/watdefs.h) and lunar (https://github.com/Bill-Gray/lunar/blob/master/watdefs.h). To avoid a conflict between the packages about which of the two places its version into /usr/include/pluto, I had instructed the auto-tarball-from-github-generation of Debian to remove watdefs.h from lunar - and then forgotten about it. Do I understand it right now that lunar is the lowest level of your libraries? I would then adjust (invert) the build dependencies of the packages.

from jpl_eph.

Even after copying get_bin.h I had problems.

I had to change line 70 of jpleph.cpp to #if !__has_include("get_bin.h").

AND

To make sub_eph.cpp happy, I had to copy date.h from lunar as well.

Once I did that, all was well.

I just updated to Visual Studio 16.8.1. Perhaps Microsoft changed something? I could have sworn years ago when I compiled this I only needed to copy get_bin.h.

from jpl_eph.

@toddcarnes : thanks for that. I just pushed commit f6fe059 to fix the first problem you mention. As noted in the commit comment, we eventually use #include "get_bin.h" a few lines further down; using angle brackets in the __has_include() directive and double-quotes for the eventual include directive was Just Plain Wrong.

It would have worked fine if you'd downloaded, built, and installed the lunar repository (which is probably what you did "years ago", I'm guessing). Doing so would put get_bin.h in the include path where both directives would find it. Same for date.h, except there, the workaround of just copying an include file to the jpl_eph directory isn't sufficient anyway; doing so will let you compile, but you really need the functions from the lunar library to get sub_eph to link. (With the caveat that sub_eph is only used to extract a range from a JPL binary ephemeris to make another, smaller JPL binary ephemeris. Not many people need to do that, which is why sub_eph isn't built by default; it's something of a niche use case.)

from jpl_eph.

For windows, I modified vc.mak

CFLAGS=/I ../myincl -O2 -MT $(COMMON_FLAGS)

myincl includes headers of lunar

and I copied lunar64.lib to the jp_eph directory

from jpl_eph.