Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make ERFA > 1.4.0 automatically pick up version info #6240

Open
3 tasks
eteq opened this issue Jun 19, 2017 · 2 comments
Open
3 tasks

Make ERFA > 1.4.0 automatically pick up version info #6240

eteq opened this issue Jun 19, 2017 · 2 comments

Comments

@eteq
Copy link
Member

eteq commented Jun 19, 2017

As mentioned in #6239, Erfa v1.4.0 includes liberfa/erfa#42, which exposes the ERFA and SOFA versions in the API.

Unfortunately, the current erfa_generator.py doesn't handle these correctly, for three different reasons reasons:

  • Some of the functions return const char* . One would expect const char* functions to return strings at the Python layer. However, the regular SOFA functions return strings via "output arguments" - i.e. char * inputs that get populated inside the function. So the current erfa_generator.py machinery doesn't know what to do with returned const char*'s.
  • Some of the functions return int . int return values elsewhere in SOFA are status codes, rather than having actual meaning in and of themselves. So the erfa_generator.py machinery handles those functions assuming they are status codes rather than values to just pass through.
  • The macros needed to actual determine the various version numbers are set in config.h in the standard erfa C build. But we don't want that in the python erfa. My temporary solution is to just hand copy the relevant 5 macros from config.h to erfaversion.c... but that's a manual solution and is not really a good idea from a maintenance point of view (it should be possible to just copy erfa over wholesale without modification).

These are all solvable problems, but probably require someone with knowledge of the Python C API... But we really should try to solve them by v3.0.0 so that the manual copying I did in #6239 is no longer required.

@bsipocz
Copy link
Member

bsipocz commented Oct 27, 2018

I suspect this isn't going to happen in the next few hours, so I remove the milestone.

@mhvk
Copy link
Contributor

mhvk commented Oct 5, 2019

Now regained relevance since the do-it-by-hand was just duplicated in #9323...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants