`make oss` rebuilds a bunch of modules unnecessarily if run repeatedly

[lf-]

What I'm doing:

$ nix-shell -p yarn libiconv stdenv openssl curl pkg-config darwin.apple_sdk.frameworks.{CoreFoundation,Security,CoreServices}  python3

$ cd eden/scm
$ make oss
$ make oss

What happens:

It seems that most of the rust crates get rebuilt when I do this, which seems broken. I am not sure why this is. I would expect that this should be a no-op and incremental compilation would be used.

Also, it seems that my local modifications to eden/scm/edenscm/hg.py are getting ignored somehow in spite of running this significant rebuild, which is both surprising and baffling. In particular, I am adding a log line to _setuprepo, which seems to make sl clone --debugger unable to b hg._setuprepo, saying "Blank or comment", which doesn't make any sense (and is also rather unhelpful since I need that to find a bug)!

If I'm using the wrong local development workflow, can we document how this should be done?

Thanks!

Environment: macOS 12.6.1 aarch64 with Nix

[sggutier]

If you are editing Python files it's usually not necessary to run make oss again. Setting the CHGDISABLE environment variable to 1 (e.g. CHGDISABLE=1 ./sl) could help with your Python issues, as it prevents the Sapling server (which could be using some of the old Python code) to be launched.

[lf-]

OH! It totally is that server. Thank you for the comment there!

I'm writing up some notes of how to work with Sapling in development, and I'll add that to them.

[sggutier]

One thing I forgot to mention: make RUST_DEBUG=1 oss runs faster, but it won't prevent the rebuild of modules.

[lf-]

Awesome, thank you! That's got me far enough that I actually found the bug I was looking for, which is now filed as #279.

I would still like incremental builds, but this is a huge improvement.

[shish]

A development guide would be very much appreciated - I've been rebuilding the code every time, and pkill'ing the daemon, leading to a total iteration time measured in hours instead of seconds >.<

[bolinfest]

FYI, the existing build process relies on distutils, which is scheduled for removal in Python 3.12:

https://docs.python.org/3/library/distutils.html

As such, we are exploring alternative options for building, so we are not planning to invest in the existing build scripts. I am optimistic that the new approach will be simpler and more reliable.

[lf-]

A development guide would be very much appreciated - I've been rebuilding the code every time, and pkill'ing the daemon, leading to a total iteration time measured in hours instead of seconds >.<

I've filed a pr to write up all the flags I've learned about so far in a guide: https://github.com/facebook/sapling/pull/287

[vegerot]

It is not ideal to have to sit through 20 seconds of webpack every time I build Sapling.

This is even a problem in the docs, where we recommend people run make oss and make install-oss because it has to rebuild all these JavaScript modules.

@strager suggested we look into if webpack has an incremental build flag. I know webpack can do this in --watch mode, but not sure about when not in --watch mode