Hi Bill,
Thanks -- I think you asked all the right questions.
JPLEPH is a pure data file. Storing it as an embedded resource
probably makes sense. I need it to be accessible as an ordinary file,
at some location that's known at execution time.
What happens if I put it, say, at ...src/wsjtx/contrib/Ephemeris/JPLEPH
? Does it then become part of the package? What tells the installer
where to install it?
-- Joe
On 6/1/2015 1:51 PM, Bill Somerville wrote:
> On 01/06/2015 18:21, Joe Taylor wrote:
>> Hi Bill,
> Hi Joe,
>>
>> I'm nearly ready to commit some new code that does EME Doppler
>> calculations with higher precision. It will require installing a binary
>> ephemeris file named "JPLEPH". I suppose this file becomes a "resource"
>> in our builds? And should it be installed in the same directory with
>> the executables? Could you recommend what's needed in CMakeLists.txt to
>> make these things happen?
> Binary contributions live under the contrib directory in the source tree
> in some meaningfully named sub directory, but see below about building.
>
> Is this executable content of pure data?
>
> If it is pure data it can become an embedded resource like the palette
> files, the benefit of this is either that the program can address the
> resource directly if it is a pure data resource and read only or that
> its copying out to the file system for use can be deferred until run
> time for read-write usage. How the data is accessed is key here. See
> below about Fortran access.
>
> If it is executable then it needs to be installed by CMake and then it
> will be packaged appropriately. The obvious question then is, how to
> deal with platform dependencies. That is normally dealt with by a
> find_<something>()CMake command and any platform specific scripting that
> may be required.
>
> Also if this is executable, what are the licence constraints that make
> it binary rather than source?
>
> A brief scan of the the info on the JPL ephemeris files it looks like
> direct access from the resource file system may not be the best place
> since the data can only be accessed from Fortan functions and they will
> not be able to read the QFile device necessary to access the Qt resource
> file system. OTOH the resource file system is a handy place to
> distribute binary files as they can be copied to the file system at
> application startup where the user writeable file locations are
> established, this is not necessarily a known location at install time
> especially on non-Windows systems.
>
> I would also suggest having the CMake script build the binary file from
> the ASCII source(s) as there may be platform dependencies like word
> width and endianism to be allowed for.
>>
>> -- Joe, K1JT
> 73
> Bill
> G4WJS.
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
