Closing remarks Participating in Google Summer of Code 2022 with NumPy was more than just contributing to a summer coding internship for me. I remember walking around my college hostel along with my friend during the first year of my engineering in 2019 discussing what do we want to achieve over the course of our undergraduate education. Back then too, I remember that my first wish ever, even before I knew what open sources was to participate in the Google Summer of Code. We study in a relatively new institution and our seniors were just graduating and the alumni were beginning to leave their mark in the world. No one had ever participated in a GSoC from our college, and barely anyone knew what it was. Nevertheless, with the help of YouTube and GitHub I got exposure to Open Source, with the GirlScript Summer of Code being the first Open Source program I participated in. Then I started participating in SciPy's pull requests, fixing its bugs and improving documentation in 2021. Slowly and steadily, I began to talk to maintainers and attend weekly Community Call meetings in the second half of the year 2021. I had never encountered such lovely and welcoming communities ever before. Neither at gaming discord servers nor at school, college or anywhere. They promoted curiosity and rewarded questions and contributions. It is as perfect a learning environment and support group a person can imagine. From the start of my exposure, I loved open source. I loved talking to these people building their exciting projects, learning from them, being a part of their communities and contributing to these projects at the cutting edge of software development. I remained an active contributor to SciPy till December 2021. In January 2022, SciPy posted their idea list for GSoC'22. Being an electrical engineering student, I first tried to go for this signal processing project but within a first couple of days discussing this project with the maintainers I could tell that there was no mentor for this project. So I switched my project preference to Restructuring F2PY frontend which I knew nothing about.

# GSoC meeting 13 -

Typing improvements, union of type with int | str requires Python 3.10+ rules.py settings generation in f2pyarg.py Improve F2PY's help message. Post distutils deprecation changes [ ] Handle --opt, --arch, --f77flags, --f90flags in more efficient way. Currently they are passed directly to the Fortran compiler. [name=Ralf] suggests that handling f77 and f90 seperately and providing compiler paths is unnecessary in his comment here - https://github.com/numpy/numpy/pull/22225#discussion_r966761955

Supporting C code https://scipy-cookbook.readthedocs.io/items/f2py_and_NumPy.html

Issue with finding module name from pyf files f2py2e's first priority is finding module name form pyf file. f2pyarg's current priority to use -m as module name must be changed accordingly. Trying to debug incorrect postlist parsing of this pyf files Diffchecker link: https://www.diffchecker.com/WEB5pi8e Support linking BLAS and LAPACK for pkg-config and CMake:

General backend structure for future f2py backends Create a structure such that backends can be added as a plugin for F2PY Compilation isn't the selling point of F2PY. So instead of having dedicated file for just building with meson, make a code structure where a supperclass Backend will provide the blueprint datamembers and functions which will be overriden by other subclasses dedicated for specific build system. Make a plugin-like code structure. Make a folder within f2py -> f2py/backends. Make a superclass Backend.py This superclass will provide blueprint for essential features.

Method 1: Trying out random stuff over the internet. Searched error trace online. This github issue has a similar error stack trace as compared to my error stack trace. Ralf suggests installing a BLAS/LAPACK distribution here. Installed Visual Studio 2022, Visual C++ redistributable 2015-22. Still getting the same error. Tried to install SciPy from source using this repo

Non compilation flags Proposal to create a service file to move all the helper functions to. change check_dir function to create directory if not exists just like f2py2e auxfuncs.options only uses verbose setting. Refactor it and shift it to service What about --coutput and --f2py-wrapper-output

Started by reading [name=Ralf]'s article on moving SciPy to Meson. It lead me to SciPy's GitHub Issue RFC:switch to Meson as a build system This article specifies in great detail features needed from a build system and how meson fulfils them. Doubt I was going through the run_compile() method, and it doesn't use crackfortran(). It just takes input source files and sends it to distutils to compile and produce the extension module. So is the C wrapper created again inside distutils? -m flag specifies module name, which is assumed untitled if not given (although I saw some wierd code tying to find module name in source file). If f2py -c source.f produces untitled shared library, shouldn't f2py source.f produce untitledmodule.c by assuming module name 'untitled'. Why the parser handling -h flag in f2pyarg.py named wrapper_generation Numpy distutils study

First thoughts Redesigning the CLI won't be complicated. The frontend structure has already been created by Rohit Goswami argparse_f2py. I just need to parse the NameSpace and call the right functions which have already been build by Dr Pearu. I will first read this CLI dev guide and write down anything related to F2PY in this doc. I can't change the design of F2PY as it needs to be backwards compatible. However, I will try to make its background functions more modular. There are a lot of big moving parts in this CLI, and breaking them up making them smaller units will probably take a lot of time considering the farther reaching implications that small changes might have. Saying just enough Currently executing f2py -c -help-compiler gives out huge amount of information: Gnu95FCompiler instance properties: archiver = ['arm64-apple-darwin20.0.0-ar', '-cr']

f2py2e.py scaninoutline() Command line parsing is done by iteratively reading CL options, modifying flag variables, and removing CL options from sys.argv array. main() : Root function Checks for some dependency flags first.

Path - https://github.com/HaoZeke/numpy/blob/f2py2eTests/numpy/f2py/tests/test_f2py2e.py Used to test the frontend CLI of F2PY Tests use [hello_world_f90, hello_world_f77, retreal_f77] fixtures that return tmpdir file paths. monkeypatch fixture patches the command line input (for eg - it changes pytest runtests.py to f2py -h fibfortran.py). f2pycli()function when executed reads the patched command line and executes F2PY.

Some doubts from f2py2e.py:run_main():L688 Flags --2d-numpy, --2d-numeric, -2d-numarray aren't being processed. Moreover, there is actually spelling mistakes. --2d-numpy --> --2e-numpy, --2d-numeric--> --2e-numeric Structure The main parser