I propose to slightly rearrange our source directories/packages.
Move cmds
Primarily, I’d like to have only useful, user-facing commands directly in cmd/. We move commands that are for backend infrastructure to cmd/infra/ and development/experimental/random stuff to cmd/dev/. Specifically, these stay where they are:
stdiscosrv stays where it is
strelaysrv stays where it is
syncthing stays where it is
These are moved to cmd/infra:
stcrashreceiver → infra/stcrashreceiver
strelaypoolsrv → infra/strelaypoolsrv
stupgrades → infra/stupgrades
ursrv → infra/ursrv
These are moved to cmd/dev (and a case could be made for just rm -r on several of these):
stcompdirs → dev/stcompdirs
stdisco → dev/stdisco
stevents → dev/stevents
stfileinfo → dev/stfileinfo
stfinddevice → dev/stfinddevice
stfindignored → dev/stfindignored
stgenfiles → dev/stgenfiles
stsigtool → dev/stsigtool
stvanity → dev/stvanity
stwatchfile → dev/stwatchfile
The end result is hopefully that it’s a bit clearer which things are meant to be built and distributed for the general user base and which are not.
Rename lib
Our lib/ should really be internal/. It even was, for a while, but then we added the discovery server and such as external repos and renamed it to lib/ so those could build. Then we moved those back in-house, but didn’t change back.
Which external things currently depend on this and would break? The iOS/mobile linking thing? The C++ linking thing in syncthingtray?
I don’t see a large enough benefit from the lib/ → internal/ rename. Sure we don’t treat it as a public interface library, as that isn’t the “product”. But when keeping up with the development pace, there is nothing wrong with using it as a library either. I think the current naming is fine and it gave me a pretty sharp idea about how those parts of the code are used. Changing it would introduce quite some source code churn.
Regarding the cmd/ restructuring, I’d welcome that part. It’s a bit crowded in there and we don’t have good documentation (anymore, it’s heavily outdated) about what is what.
Yep, the ios app uses lib/syncthing - c++/syncthingtray afaik does not, that attempt was abandoned. In principle I like moving everything to internal, except lib/syncthing. Afaik that clearly defines the expectations, nobody should depend on our code as we don’t treat it like library code - we break interfaces at will at any time. Practically though it would be a lot of work: Through lib/syncthing types of other packages are exposed, see e.g. Code search results · GitHub A bunch of that could be improved, as in expose less in lib/syncthing by moving some of his code as generic helpers to lib/syncthing. However again, it’s a bunch of work.
I’m using Syncthing as a library but I guess I’m prepared to do the necessary conflict resolution when rebasing. If files are mainly moved around this shouldn’t be problematic at all. Otherwise it might be a bit more involved but probably nothing to be afraid of
syncthing stays where it is
This makes it sound like there might not even be a conflict at all (for what Syncthing Tray is using at least).
No, it was not abandoned. (The GNU/Linux packaging is not using it because there it makes more sense to simply depend on the distribution-provided syncthing package. My other builds provide it and I think it makes especially sense under Windows. I also plan to use it for future Android builds.)
