Automated win32 build scripts and UPDATE_SOURCES, packaging dir,...

[Derek Atkins]

Geert,

I think there are two different types of builders:  the automated builder,
and a developer.

The automated builder is always going to want to build the most recent
changeset on any particular branch, and it's going to want to be able to
update the build scripts while doing so.

Developers probably do NOT want to sources to auto-update, and instead
would probably want the build to work with the code as-is without an
update.

I do think we need to support both situations.

-derek

On Sat, August 11, 2012 11:29 am, Geert Janssens wrote:
> I have just added some scripts to run an automated build from git
> instead of svn.
>
> I copied the svn behaviour as closely as possible. While doing so I got
> to question parts of the general setup we promote [1]. The guidelines
> state that the contents of packaging/win32 should be copied locally, and
> it shouldn't be in the repo checkout that will later be used for building.
>
> I see several issues with this, some of which may be easier to fix than
> others:
> - I first wondered why the packaging directory should be separate from
> the repo used to build. After some pondering I came up with this: when
> UPDATE_SOURCES=yes, and we're using the packaging dir from the repo, the
> install scripts may update from under us while building. Obviously not
> good.
> - So I started thinking about UPDATE_SOURCES. Why is that option in
> there ? I suppose for the "automated" mantra. Having it in there, allows
> you to always build the most recent state of a branch. I wonder though
> if this benefit outweighs the restrictions and limitations it brings
> with it.
> - Copying the packaging directory is a bootstrap thing and has other
> issues: the guidelines don't explain how to copy this directory. On a
> clean Windows system your option is to manually download each file or
> use some kind of download manager. At this stage the user isn't supposed
> to have svn or git available to checkout the directory - that means the
> guidelines don't ask him to do so, because it will be installed later on
> "automatically". This looks like a hurdle to me for new potential
> contributors on the Windows platform (there are many more, I know...)
> - Next, by simply copying the files to a local directory, the user
> looses the main advantage a checked out repo has: easy update to newer
> versions of the build scripts. The user has to guess if/when the scripts
> were updated and manually copy the over again from somewhere. So if the
> user isn't careful, later builds may be using outdated build scripts.
> - The fix for the last problem would be to use some form of checkout of
> the packaging directory. But at bootstrap time, there's no subversion or
> git available. That can be solved by asking the user to install either
> tool manually.
> - For svn, the story ends here. The user uses svn to checkout the
> packaging directory and continues the setup. To get the most recent
> build scripts, it suffices to run svn update.
> - But for git users, there's another catch: git doesn't allow to
> checkout one directory only from a git repo. So to satisfy the original
> requirement (separate packaging directory) he needs to clone the
> complete git directory. The build itself will clone it once more. That's
> twice the disk space for the complete gnucash repository used for only
> ten or something scripts.
>
> And all that because UPDATE_SOURCES risks of invalidating the build
> scripts mid-build.
>
> I see two possible fixes:
> - drop UPDATE_SOURCES. It's not that hard to update your build repo for
> either svn or git. For git which is much more branch focussed than svn,
> I think an active developer would probably disable UPDATE_SOURCES
> anyway, because it would rarely do what you actually wanted. With
> UPDATE_SOURCES out of the way, the bootstrap procedure would be
> something like: install your favourite revision control tool, check out
> the proper repository, (the other bootstrappers, such as mingw-dtk,...),
> cd into packaging/win32 and off you go. This could still work with
> building from tarball as well.
> - alternatively if UPDATE_SOURCES is to stay, we could also move the
> packaging/win32 directory to a separate repository (similar to what the
> OS X build does). That would allow UPDATE_SOURCES to remain and have a
> local packaging directory that is revision controlled from the start.
> Doesn't make much difference for svn users, but for git users the
> separate packaging repository would be a small clone instead of having
> to checkout the whole gnucash repository. So for this solution the steps
> would be: install your favourite revision control too, checkout the
> packaging repository. Do the other bootstrapping stuff and off you go.
> The packaging repo can be updated whenever needed.
>
> Personally I prefer the first option. From a new user's point of view it
> would look so much more intuitive to be able to either install a tarball
> or the preferred rcs and checkout the proper repo and from there on
> start building (I deliberately ingore some other bootstrap steps here to
> create the picture). But the second option would work as well for me.
>
> What do others think ? Is my reasoning correct ? What do you see as
> solutions ?
>
> Geert
>
> [1]
> http://wiki.gnucash.org/wiki/Windows#Instructions_for_an_.28almost.29_automated_build
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>