BLD: Meson __config__ generation#22769
Conversation
|
Hi @rgommers , I've made a POC of what I had in mind and wanted to know if this is the right approach for the requirement. I can continue based on feedback. |
|
Since this only contains information known at the time of configuration, I wonder if it's necessary to have a generator script at all? Maybe passing a dict in meson to a The main difference is that it requires less work and one less build edge. |
|
Ah ok that makes sense. Something like this yeah? |
That example is not the best (the if-else could use a single Line 423 in a24ddad |
aa0a2f5 to
1a7680e
Compare
|
This looks pretty good at first glance @ganesh-k13. I added some comments, will do a proper review later. |
1a7680e to
942e971
Compare
| "PYTHON_PATH": "@PYTHON_PATH@", | ||
| "PYTHON_VERSION": "@PYTHON_VERSION@", | ||
| }, | ||
| "SIMD Extensions": { |
There was a problem hiding this comment.
As of today it's empty and get's removed by _cleanup (including the top-level key), but should work once we add SIMD. I'll keep a look out and test it post that, or I could remove it now and add it later.
|
Are we planning on using Meson Tests? I was exploring how to add UT. If it's in the plan, I can start the test framework with this module, else I'll stick with pytest and see how to test this. |
|
If you've already heavily invested in pytest, meson test doesn't add much. Particularly, there's not a whole lot of benefit in taking one test harness/reporter (meson test) and using it to run another one (pytest). You can do it, but it will just result in meson test reporting on a single test (that is, whether running It's really meant for cases where you don't have an existing test harness, and want to set one up. Particularly, when tests are run as a series of test programs rather than in-process setup/teardown. You can use a TAP reporter for pytest, then tell meson to read the Meson Test via the TAP protocol, that does get you subtest reporting. But pytest is already pretty nice as is so it's work for no clear gain, and passing options from |
rgommers
left a comment
There was a problem hiding this comment.
Hi @ganesh-k13, I did some testing. It all seems to work, my main observation is that the output is quite difficult to read. For comparison, let's have a look at show_runtime, show_config and the output of Meson itself:
In [2]: np.show_runtime()
[{'simd_extensions': {'baseline': [], 'found': [], 'not_found': []}},
{'architecture': 'SkylakeX',
'filepath': '/home/rgommers/mambaforge/envs/numpy-dev/lib/libopenblasp-r0.3.21.so',
'internal_api': 'openblas',
'num_threads': 24,
'prefix': 'libopenblas',
'threading_layer': 'pthreads',
'user_api': 'blas',
'version': '0.3.21'}]
In [3]: np.show_config()
Out[3]:
{'C Compiler': {'C_COMP': 'gcc',
'C_COMP_LINKER_ID': 'ld.bfd',
'C_COMP_VERSION': '10.4.0',
...
And the Meson configure output:
C compiler for the host machine: /home/rgommers/mambaforge/envs/numpy-dev/bin/x86_64-conda-linux-gnu-cc (gcc 10.4.0 "x86_64-conda-linux-gnu-cc (conda-forge gcc 10.4.0-19) 10.4.0")
C linker for the host machine: /home/rgommers/mambaforge/envs/numpy-dev/bin/x86_64-conda-linux-gnu-cc ld.bfd 2.39
C++ compiler for the host machine: /home/rgommers/mambaforge/envs/numpy-dev/bin/x86_64-conda-linux-gnu-c++ (gcc 10.4.0 "x86_64-conda-linux-gnu-c++ (conda-forge gcc 10.4.0-19) 10.4.0")
C++ linker for the host machine: /home/rgommers/mambaforge/envs/numpy-dev/bin/x86_64-conda-linux-gnu-c++ ld.bfd 2.39
Cython compiler for the host machine: cython (cython 0.29.32)
Host machine cpu family: x86_64
Host machine cpu: x86_64
...
The capitals, hard to understand names and returning a dict of dicts instead of actually printing all contribute to the output being tricky for the reader to parse. I suggest changing the keys of the dict being as easy as possible to understand. And then also providing an option to print to stdout rather than returning a dict of dicts.
A few examples to make that concrete:
'BLAS_VERSION': '0.3.21',
I'd make that 'version': '0.3.21' (it's already under a BLAS key).
'LAPACK_TYPE_NAME': 'pkgconfig',
I'd make this: 'detection method': 'pkgconfig',
|
Yeah, that's a really good point! In fact Matti had a similar idea in the previous PR(#20939 (comment)). I'll make those changes 👍 |
942e971 to
ee6b49c
Compare
|
I have added |
ee6b49c to
7875c1b
Compare
|
Overall I think we can refine the keys a bit to make more sense. I'm torn between making it programmatically accessible vs human readable, for example: |
rgommers
left a comment
There was a problem hiding this comment.
This is getting close! Just a few minor comments, and docs left to be added.
I think optimizing for human-readable when printing sounds fine to me. I think that's the first thing people will do. Programmatic access is important too, but it's fine is that requires say a space in the key of a dict. |
d15c981 to
eaf2b21
Compare
|
When you think this is ready to merge, please take it out of Draft mode and let me know - happy to get this in soon:) |
|
I didn't realise it was draft. Yeah almost ready, I'll just restrict the tests. Does it need a release note as show_config takes args now? Or we just wait for distutils to go and add one big release note? |
|
distutils to go is probably ~5 months away, so let's not wait for that. |
eaf2b21 to
f4db5d0
Compare
* Adds a new env in `__config__` to indicate if built with meson
f4db5d0 to
4f5905a
Compare
* Removed `Target` from host info * Fixed warning with using compiler `path` * Added `cross-compiled` flag
|
Hey @rgommers , any more changes needed on this PR? |
rgommers
left a comment
There was a problem hiding this comment.
Thanks for the ping @ganesh-k13, I missed the last update. This looks good to go now, time to merge it. Thanks a lot for getting this over the finish line!
|
I am running into a circular import trying to add a flag to the main namespace. I could change that design to be a getter or move the initialization around. But I am wondering if we can move the C imports here back to be done lazily to avoid importing C until later? |
|
Nvm, it is nice to |
|
We could refine the cleanup to take place in the actual function and move the import inside. I think that's cleaner as well. Shall I do that? I feel we will hit this in the future. |
|
I think it is fine as is, thanks. I had added the The only thing I could think of doing would be to make it a bit more obvious where the C-module is imported the first time (which is also the place guarded by this?): I think. Maybe with a comment that things that used from C must be defined before or live live in |
Changes
Add functionality to autogenerate build information from Meson information
In order to add new information, do the following:
numpy/meson.build__config__.py.into accept the new argumentNew
__config__.py:'print' mode
'json' mode
'print' mode no PyYaml
TODO
Remove__config__.py.inBuild Dependenciesrelated: #20939 (comment) | scipy/scipy#16803