[Unison-hackers] rc not yet, naming of GUI

[Greg Troxel]

(I have not made an rc, because there is now a lot of activity that is
leading to mergeable improvements.)

unison's build system has a notion that one builds with a UISTYLE, and
this produces a binary "unison" that either does or doesn't have a GUI.

For an individual building unison, this is fine, but it doesn't play
well with packaging systems.  As I understand it, some packaging systems
build it both ways, so that there is unison (text) and unison-gtk (GUI).
(pkgsrc has an option, which defaults off, partly because of this
problem, and partly to avoid depending on gtk2.)

Recently, issues have come up in CI where tests need to be run on the
text version (because of another issue that can be fixed), and thus
there is sequencing of build text, test, build GUI as a workaround.

These two things, packaging system decisions and test awkwardness, argue
strongly that building two different things to the same filename is not
an ok thing to do.  This is captured in
  https://github.com/bcpierce00/unison/issues/394

I think this is pretty easy to fix, and we just need to pick a name for
the GUI build.
The only two I've seen talked about are

  unison-gtk
  unison-gui

The first is in use by packaging systems, so that is less of a change to
many people.  The second is more general.

Looking forward, we hope to move to lablgtk3:
  https://github.com/bcpierce00/unison/issues/358

but I see that as a move, not being a new option (gtk2 is obsolete).
unison-gtk remains a good name for that.

(However, I can see the point of picking unison-gtk2, and later gtk3.  I
favor making UISTYLE=gtk the norm, with gtk2 a deprecated alias.)

Should there be some gui that isn't gtk, that might well need a
different name, but it is very likely that whereever that new thing runs
gtk would too, so a new name seems good.

I will observe that if people want 'unison' to be the gtk system on
their installed system, they are free to do that, similarly to how
packging systems have made the reverse change.  We could add an install
target "install-gtk-as-unison" that is like "make install" but installs
unison-gtk as unison.

The biggest reason to do this is to avoid a lot of difficulty in making
the build/test/install/packaging process work, and work with CI, and
right now that difficulty is falling on a very small number of people.

(There is perhaps another issue, which is that individual object files
may be built differently and thus need to be in separate dirs, but if so
that is far less important and can be addressed as a further step.)


So, are they any objections to a commit that would read like

  Change GUI build to create unison-gtk

  When builing with UISTYLE=gtk2, place the compiled binary in
  unison-gtk rather than unison.  This avoids overwriting the previous
  UISTYLE=text build and thus avoids conflicts with CI.  It regularizes
  the notion of which program name has GUI support, aligning with
  existing packaging.

followed by commits to packaging and CI/etc. that adopt to this.  A bit
of a kerfluffle, but very low risk of hard-to-debug trouble.

Greg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://LISTS.SEAS.UPENN.EDU/pipermail/unison-hackers/attachments/20201110/2ef76e01/attachment-0001.asc>