Hi, I have been building php binaries for core and extension automaticaly for more than a year, without any problems. I have a set of scripts (.cmd files) that updates my cvs tree, builds core and extensions and then copies the files to my website. The scripts are run each morning a 4am by the scheduler on my Windows 2000 box.
Using command line scripts with MSDEV enables you to use the build environment defined in your Visual Studio settings, but it also allows you to work with environment variables (INCLUDE and LIB) without actually changing your settings permanetly. If you are interested in the scripts I would be happy to share. - Frank > From: Wez Furlong [mailto:[EMAIL PROTECTED]] > > I'm in the process of getting a more permanent win32 build environment sorted > > out, and one of the things I'd like to do is avoid the VS IDE as much as > > possible, and automate builds so that I can test changes that I make under > > unix. (Perhaps even by rshing to my win32 box). > > > > I know it's possible to build projects from the command line using something > > like "msdev xxx.dsw", but so far I've not succeeded (and have little patience > > with win32 and the command line, because it is generally quite limited). > > > If you try to do automated builds through "msdev" you run two risks: > > 1. The build environment is somewhat uncontrolled. > 2. The IDE under some conditions will throw up dialogs and stop. > > The first concern is with the global environment inherited from MSVC > and used in the build. MSVC pulls in libraries and include files from > you-don't-know-where and this makes it more difficult to know exactly > what has changed between builds. > > If the machine used for automated builds is strictly controlled, and > used for nothing else this is less of a risk. > > The second concern is simply that MSVC was designed as an interactive > application and may at any time decide to ask a question of the user > by presenting a dialog. Naturally this brings an automated build to > a complete stop :). You may on occasion have to check the box doing > the builds to make sure it has not become stopped in this fashion. > > > There is another approach to this that is a more hassle, but is without > the above problems. > > In MSVC you can say "Projects | Export Makefile..." for all projects. > This generates nmake makefiles (*.mak) for all projects in the workspace. > > If you then specify the *exact* environment variables set when you run > nmake then you know *exactly* the build environment in effect. > > For my production builds (anything that might be shipped to a customer) > and only after all the unit tests pass, I use a Perl script to: > > 1) Set the environment to use in the build. > 2) Update local sources from CVS. > 3) Bump the build number (updates version .h and .rc files). > 4) Run "make clean". > 5) Commit all changes to CVS. > 6) Run "make dist" to build a distribution. > 7) Tag the sources in CVS with the build number. > 8) (Optional) upload the distribution to an FTP server. > > The exact same build script works in exactly the same way (with the > exception of the platform-specific makefiles) on Unix, Windows, and > (in one case) on OS/390. > > OK - so maybe this is a lot more complicated :). > > The upside is that from the build number compiled into the executables > you know *exactly* the sources and build environment used. There are > no manual intermediate steps and no possibility of human error. > > -- > Preston L. Bannister > http://members.cox.net/preston.bannister/ > pbannister on Yahoo Messenger > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
