[Buildbot-commits] [Buildbot] #971: Build a windows installer

Tue Jul 26 16:56:07 UTC 2011

#971: Build a windows installer
------------------------+-----------------------
Reporter:  dustin       |       Owner:  fatman2
    Type:  enhancement  |      Status:  accepted
Priority:  major        |   Milestone:  0.8.+
 Version:               |  Resolution:
Keywords:  windows      |
------------------------+-----------------------

Comment (by fatman2):

 Replying to [comment:25 jollyroger]:
 > Replying to [comment:24 fatman2]:
 > > monolithic installer ... the whole thing can and should be automated
 ... administration program ... admin icons
 >
 > run some "New buildbot instance" wizard right after the installation ...
 there should be a link for it in "menu" group ... wizard should solve
 this. On this stage you'll have already installed buildbot code (with no
 instances) and are in the process of creating a new instance. Even if you
 cancel this operation, this won't affect the installer since it has
 already exited. But you'll be able to run the operation again from the
 menu group.

 This is starting to sound good. The more I think about it, though, the
 more unhappy I become with the idea of the Start Menu as a place to put
 configuration icons. Surely we should be using the Control Panel instead?
 That's what it's designed for. Plus, a Control Panel would be more fun to
 code up. ;)

 > > hardcoded paths ... "Program Files" problem
 >
 > every Python environment will write its $PYTHONDIR/Scripts into the
 $PATH variable

 This raises the spectre of "version hell", which I suspect might have been
 part of the cause of my troubles installing. Suppose we have the Buildbot
 script installed in three Python versions and all the relevant paths in
 PATH. (I'm not sure why we'd do that, except for testing.) We'd have to be
 very careful to pick the right one every time.

 > there is a common structure for binary distributions of Python modules
 (including buildbot)

 I knew there was a reason I liked Python.

 > ask Python generate binary distribution

 Here's a random thought, since we're talking about binaries: is it
 possible to get Python to generate native PE binaries from scripts? It's
 usually done by embedding the needed scripts in a tiny redistributable
 interpreter stub, but I don't know if Python supports that. If we could do
 that, all the Python issues would go away.

 > > no dependency
 >
 > it happened that your CMakeLists.txt required cl.exe just to generate
 makefiles

 No, it doesn't. It's just that the default compiler selected by CMake on
 Windows is Visual Studio, a not unreasonable assumption given zero
 knowledge. You have to tell CMake what makefile generator to use, like so:

 {{{
 cmake -G "MinGW Makefiles" ..
 }}}

 If you try it now, CMake will complain. First you must delete... I think
 it is... the CMakeCache.txt file. Failing that, delete all the CMake-
 generated files.

 The double-dot, by the way, selects the CMakeLists.txt in the parent
 directory. I like to keep my CMake build files well away from the source,
 so I can delete the whole lot without deleting my entire source tree.
 (CMake has no equivalent of "make clean".) That's the purpose of the
 "cmake" dir you saw in my fossil. It's just there to catch all the files
 put out by CMake.

 > I think anyone willing to look on windows installer will in the end be
 much confused with this much of unneeded code and software required just
 to build an installer

 I don't understand what you mean. I've been through both the NSI scripts
 in the fossil and I can find no references to CMake. CMake is simply not
 required for my NSI scripts.

 > > needs to be done
 >
 > See my code and maybe try my installer, I've already implemented
 installing buildbot to different installed Python versions at once.
 However this will be reworked to add dependencies subsections for each
 Python distribution.

 Cool. Did you come up with a way to avoid version hell? We wouldn't want
 to uninstall the wrong Buildbot.

 > > creating and destroying herds
 > The problem is that we can make Buildbot menu group overbloated with
 lots of options

 Yes, this also worries me.

 > because there are lots of parameters to vary. I suggest to have "New
 master wizard" and "Uninstall master" menu options in the root of buildbot
 menu group together with "instances" directory. Each directory would have
 subdirectory in form "<bot name> (Python <PYTHONVERSION>)" with links to
 start, stop and remove bot (and maybe additional option:configure, if
 someone will write a gui someday, but this is a kind of silly).

 Maybe not so silly and not at all hard if we go with the Control Panel
 applet. For instance, we could make the applet contain a browser control
 and code up the options in HTML. That's just one idea.

 > > discussion needed
 > Here what I'm thinking about this. Buildbot installs all its code inside
 the Python environment. This means we don't need an extra directory in
 Program Files. However there is only uninstaller that has nothing to go.
 It would be wrong to put uninstaller only in one Python environment,
 because all other Python environments are neither worse nor better.

 It seems just as wrong to create a Program Files subdirectory just for an
 uninstaller. Even worse would be putting the uninstaller in C root, or in
 WINDIR. The Control Panel applet doesn't suffer from this, though. It
 could arrange to delete itself on next boot by using the RunOnce registry
 keys.

 > I mentioned two ways of uninstaller's logic: remove the buildbot code
 just from current Python environment or remove it at all. However, when I
 think about it, this may require to have lots of menu groups like
 "Buildbot for Python 2.4/2.5/2.6/2.7" or relative subgroups in general
 "Buildbot" menu which is not very great too.

 I think we have to consider the Buildbots themselves first and the
 versions second. Suppose I have these Buildbots installed:

 {{{
 Project: p1
 Type: Master
 Python: 2.7

 Project: p1
 Type: Slave
 Python: 2.6

 Project: p2
 Type: Slave
 Python: 2.5
 }}}

 With a few clicks, I should be able to uninstall a) all Buildbots, b)
 Buildbots working on project p1, c) Buildbots running in Python 2.5, d)
 all masters or all slaves, and e) individual Buildbots.

 > If we can write additional uninstaller page to give a possibility to
 remove buildbot code from desired Python environments, this would be uber
 great.

 I think this might be a wrong way to go. But I'm not sure.

 > NSIS can generate lots of equal uninstallers and I checked that already.
 All is left to do is to store install options to register during
 installation, read them during uninstall process, remove the buildbot code
 and all uninstallers that left behind.

 Yeah, NSIS is great for little self-destructing uninstallers. I'm still
 not sure how it can do that.

-- 
Ticket URL: <http://trac.buildbot.net/ticket/971#comment:27>
Buildbot <http://buildbot.net/>
Buildbot: build/test automation