You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By clicking “Sign up for GitHub&
8000
rdquo;, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
The test for #26703 exposed a new regression instance.
The testcase was specially crafted to test passing flags
"specially crafted" in this case means it will build a module, though it cannot be imported, since the parser doesn't pick up the subroutine name
Not sure if this is actually going to be a problem for anyone, nor is it clear that this is a regression, earlier versions (1.26) with distutils also seem to generate the same broken module
Actually this does work with 1.19.5 so there's another regression lurking with the parser for F77....
Basically strictf77 should be set if -ffixed-form is passed, irrespective of the file ending...
Since the same code works if its in a .f file
The issue is that F2PY while generating wrappers needs to know if the files are F77 or not, and the compiler arguments are not transparently available to it.
However, this is really a bit of a weird state, it isn't a great idea to have the compile time arguments "bleed" into the meson setup.
Here are the concrete questions:
Since F2PY is meant to generate a meson.build (sometimes) and therefore should take fortran_args shouldn't the crackfortran and other parts also be aware of these arguments?
On whole I'm veering towards a wont-fix since:
F2PY isn't really a meson.build generator, it is primarily to generate the corresponding wrapper code
In doing so, it wouldn't make sense to expect --fflags to provide information on weather the file should be parsed as a Fortran 77 file or not
The current (not so robust) way is to check the filename, and also the arguments passed (e.g. -fix-f77 etc)
This will be a non-issue (trivially fixed) if / when the various different interfaces to calling F2PY are unified (noted elsewhere, but we currently have one path without -c one with, and additional argument handling in crackfortran.py, all of which basically do not talk to each other and bleed state).
The text was updated successfully, but these errors were encountered:
The test for #26703 exposed a new regression instance.
distutilsalso seem to generate the same broken module1.19.5so there's another regression lurking with the parser for F77....strictf77should be set if-ffixed-formis passed, irrespective of the file ending....ffileThe issue is that F2PY while generating wrappers needs to know if the files are F77 or not, and the compiler arguments are not transparently available to it.
However, this is really a bit of a weird state, it isn't a great idea to have the compile time arguments "bleed" into the meson setup.
Here are the concrete questions:
crackfortranand other parts also be aware of these arguments?On whole I'm veering towards a wont-fix since:
meson.buildgenerator, it is primarily to generate the corresponding wrapper code--fflagsto provide information on weather the file should be parsed as a Fortran 77 file or not-fix-f77etc)This will be a non-issue (trivially fixed) if / when the various different interfaces to calling F2PY are unified (noted elsewhere, but we currently have one path without
-cone with, and additional argument handling incrackfortran.py, all of which basically do not talk to each other and bleed state).The text was updated successfully, but these errors were encountered: