Migrate bliss extension to meson

[tobiasdiez]

WIP

Follow-up to #36524.

📝 Checklist

• The title is concise and informative.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.
• I have updated the documentation and checked the documentation preview.

⌛ Dependencies

[tobiasdiez]

After thinking more about this, I don't see the point of these modularized distributions. Meson is now able to selectively build the bliss-part of sage depending on whether bliss is installed or not. Thus a separate module where bliss is marked as required seems to be rather pointless to me. I guess the only advantage would be shipping a binary wheel that includes bliss, but that could also easily be done as part of the main project. In summary: if someone wants to continue here, please feel free to do so.

@dimpase @orlitzky if you want to create a giac package, you can take this PR here as a blueprint.

@kwankyu The "Build and Test" are failing without any error message. I had this in a couple of PRs, mostly when there are compilation errors. This is rather inconvenient. Could you please fix this (My understanding is that you are one of the very few that understand the CI infrastructure)?

[dimpase]

@tobiasdiez - I agree.

I am busy with the move now, till next week.

[orlitzky]

I only see the value if they are moved to a separate repository, but there are now many more important things to do, like move all of the ./configure checks into meson, and figure out a way for the meson equivalent of --disable-foo to actually disable foo (rather than have it slowly autodetected at runtime over and over again).

[tobiasdiez]

figure out a way for the meson equivalent of --disable-foo to actually disable foo (rather than have it slowly autodetected at runtime over and over again).

That's easy to do. If you tell me what you want to disable, then I can prepare a PR.

(Btw, meson caches its dependency checks - at least if they provide pkgconfig data.)

[dimpase]

I only see the value if they are moved to a separate repository, but there are now many more important things to do, like move all of the ./configure checks into meson, and figure out a way for the meson equivalent of --disable-foo to actually disable foo (rather than have it slowly autodetected at runtime over and over again).

If this would allow us to get rid of the sage.feature things (or at least some of them - runtime checks for libraries are really a weapon of last resort), it would be a great simplification.
I believe that sage.feature was introduced in the 1st place to overcome the shortcomings of the build system.

[orlitzky]

One example is ffmpeg. It is occasionally installed on the user's machine, but if they build sage with -Dffmpeg=false, then sage shouldn't opportunistically make use of it (and ideally shouldn't even ship the code to use it, but more on that later).

In the interim what I imagine is three levels of feature support: yes, no, and maybe. If the user builds with -Dffmpeg=true, then the feature is enabled and should not be detected at runtime (the "feature" should return const true). On the other hand, if they build with -Dffmpeg=false, the feature should return const false. Finally, if they specify neither of those, it could be detected at runtime. We would accomplish all three by having meson write the variable (True/False/None) to its config module, any by having sage.features.ffmpeg consult it.

Having any sort of runtime detection is undesirable, but in this example it's nice for binary distros and users who don't want to rebuild all of sagelib just to pick up /usr/bin/ffmpeg. Longer term I think it would be better to eliminate the runtime detection and move ffmpeg support into (say) sage.misc.ffmpeg which could be installed independently and would supply its own config value overriding the build-time one. But that would require extracting the ffmpeg bits from sage.plot.animate first, and while it's certainly possible, it's one more thing to do, and may not be easy in the general case.

[tobiasdiez]

This makes a lot of sense. I would wait, however, with implementing this until we have faded out the old setuptools-based build and only use meson. Otherwise we have to implement many workarounds since we cannot rely on the build system to check for things during build time.