On Thu, Oct 22, 2015 at 11:28 AM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote: > On Thu, Oct 22, 2015 at 08:36:49AM +0300, Yedidyah Bar David wrote: >> > >> >> Makefile | 100 ++++++++++++++++++++++++++++++++++++ >> > >> > one adding the Makefile >> > >> >> automation/README.md | 8 +++ >> >> automation/build-artifacts.packages | 10 ++++ >> >> automation/build-artifacts.repos | 2 + >> >> automation/build-artifacts.sh | 21 ++++++++ >> >> automation/check-patch.packages | 10 ++++ >> >> automation/check-patch.repos | 2 + >> >> automation/check-patch.sh | 21 ++++++++ >> > >> > one adding the automation bits >> > >> >> ovirt-wgt-installer.spec | 63 +++++++++++++++++++++++ >> > >> > one adding the spec file >> > >> >> win-guest-tools.nsis | 31 +++++++---- >> > >> > and one adding the *VERSION variables >> >> Not sure about this one. >> >> I move here the maintenance of VERSION from the nsis file >> to Makefile. >> >> If you really want to split them to two changes, I have to >> carefully create a minimal Makefile just allowing this. >> >> I probably already did at one point, can check previous versions of >> the change in gerrit. >> >> Is it really that important? > > I was thinking having first the version changes in the .nsis file, and > then adding the Makefile. I think in this order you don't need a minimal > Makefile (?). Technically, of course you don't. make can't do things you can't do manually. But if the intention is to keep VERSION maintained, as opposed to just dropping it, only to do that in the Makefile and not in the nsis file, you need a Makefile for that. > Having smaller/more focused commits will allow to have > more specific commit logs :) Perhaps I should instead provide more details in the commit message, if that's the issue. Anything missing specifically? > With this commit as is, I don't know what > is the reasoning for having variables for the installer/uninstaller > names, The reasoning is to not duplicate these names in both the makefile and in the nsis file. Both of them need to know these names, and it makes more sense to me to maintain these names in the Makefile and pass to makensis. Obviously the nature of make makes it somewhat easier to override from outside when actually running it, but I do not intend to do that for now. We might eventually use this if we decide to use this project also for downstream (RHEV). > nor how the 2 version numbers are meant to be used/what they mean > (arbitrary user-visible version number for the built installer, version > of the installer code, ...). No problem adding such text to the commit message. > > Christopheh -- Didi _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel