On October 18, 2025 9:58:27 AM CDT, Travis Scrimshaw <[email protected]> wrote:
>Silent by default is still silent. I've changed element.pxd only to revert
>my change (and require no changes to cython otherwise), so I wanted to
>forgo basically rebuilding all of the cython files until I had to.
no sane timestamp-based build system will let you do this, and for a good
reason.
I've never heard about "ignore dependencies rebuild".
You could spend some time working on the Sage-distro build system, where any
file change triggers a coffee-break, i.e. the whole bootstrap+configure+make
run. :-)
>If I
>just then saw that Sage was hanging while trying to start, I would think my
>build is completely broken somehow, we'd spend forever trying to debug it,
>only to realize it would be working as intended. This is the same for this
>meson setup build that is taking forever with no visible output for over 10
>minutes (as per the other thread).
I explained how to make it visible, and this is documented. And yes, these long
delays are fixable, it just needs more work.
It's not in any way unique. So we basically turned the whole sagelib into a
JIT-compiled system, and similar JIT- compiled systems, e.g. anything
Julia-based (for instance Oscar) are similar in spirit (and startup time could
be like this too..)
Or if you use VSCode or a similar JIT system to write LaTeX, you'll also see
delays in redisplaying pdf, too...
>
>There is a strong case to be made for Python files automatically being
>reloaded. This is how Python works, both in the language design and
>interpreter design. Cython is completely different being a (not JIT)
>compiled language. Moreover with it being (default) silent despite the
>Cython compiler having output is really bad. Imagine if your favorite C
>compiler was silent by default.
$ gcc helloworld.c
$
It IS silent, sorry.
Sure, we can make sagelib rebuilds noisier by default if there is sufficient
demand.
Dima
>
>Best,
>Travis
>On Saturday, October 18, 2025 at 11:12:01 PM UTC+9 Michael Orlitzky wrote:
>
>> On 2025-10-18 14:26:34, Oscar Benjamin wrote:
>> > The meson-python editable setup that it sounds like sagemath now uses
>> > is available as `spin install` but I don't use that because I prefer
>> > running spin commands to trigger a rebuild explicitly.
>>
>> We switched to editable installs a long time ago (way before meson)
>> because people kept starting sage without running "sage -b", and then
>> were confused that their changes didn't take effect. If you're willing
>> to forego that ability, a non-editable sage build already works this
>> way.
>>
>> The meson commands take a few days to get used to, but they're much
>> more flexible than the spin counterparts. There are thousands of
>> projects that use meson, and only a few that use spin. If you're going
>> to learn a new set of commands either way, why not learn the more
>> useful set?
>>
>> A non-editable workflow[0] is basically...
>>
>> $ meson setup --prefix="${HOME}/.local" build
>> $ meson install -C build
>> <do whatever>
>> $ meson install -C build
>>
>> This does incremental builds, only when you ask for them, and then
>> installs the result to your user's PYTHONPATH so that no magic
>> commands are needed. To use it, you just run `python` or `ipython`.
>> Knowledge completely transferrable. You don't even need pip!
>>
>>
>> [0] Sage overrides one of the defaults, so you also need to pass
>> --python.install-env=prefix when configuring sage. But any other
>> meson-python project should work this way out-of-the-box. Also
>> note that "build" needs to be changed for sage due to the distro
>> files living there.
>>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/sage-devel/6C11E209-1A83-4E6C-8549-ACCCCF2B9222%40gmail.com.
