On 01/06/2015 19:10, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> 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?
OK, I have added a new static data location to the WSJT-X configuration. 
To install a file there add something like this to the top level 
CMakeLists.txt

install (FILES
   contrib/Ephemeris/JPLEPH
   DESTINATION ${WSJT_SHARE_DESTINATION}/${WSJT_DATA_DESTINATION}
   #COMPONENT runtime
   )

 From within WSJT-X you can access the new directory by using the 
Configuration::doc_dir() method. If you need it in jt9 then a new 
command line option will be needed.

This should be platform agnostic and fully compatible with packaging.
>
>       -- Joe
73
Bill
G4WJS.
>
> 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


------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to