[CentOS-devel] Ja oder nein: is cygwin-setup process a viable alternative to present day builds?

Sat Feb 19 02:15:05 UTC 2011
Phoenix, Merka <merka.phoenix at hp.com>

On 18 Feb-2011 15:16, Larry Vaden wrote:
> Because 4 of our servers are Windows boxen running IIS (to enable small business
> folks to build web sites with Front Page), considerable fondness for the cygwin
> build process has developed to the extent that Windows commands via CLI and GUI
> are hardly ever done.
>
> At the end of the day, other than RPM package management, what are the substantial
> differences that would preclude a cygwin-setup-like build process from being used
> to build and maintain the release and would it be a lot faster and less labor
> intensive?

If you only have Microsoft(R) Windows(R)-based servers available,
then why not run the build process on a virtual machine that is running Linux (RHEL or CentOS?
(granted the best scenario would be to have native Linux(R)-based system, but if you have to share... :-)

If you have four servers that are MS Windows/MS IIS (perhaps are the only h/w available?),
install VMware(R) Player (or VMware(R) Server) to run a true Linux "server" on the same h/w along side the Microsoft Windows operating system on one of those servers.

It wouldn't require replacing the MS Windows operating system (nor would it require a dual boot).

This would give you the same tools to handle the builds plus the RPM package management.

Building your RPMs on Linux (RHEL or CentOS) would also give you a better chance of those same RPMs running that Linux distribution.
Compiling the executable/objects with the same GCC toolset, linked against the same libraries also ensures that the executable will run correctly under RHEL or CentOS. This reduces the possibility of GCC compiler or library versions not matching those used under RHEL/CentOS.

And Linux instance running in VMware Player would still give you the cut & paste capability (between host and guest)
and could "mount" a directory from the host to facilitate file copies between the "host" and "guest" operating systems.

VMware Player cost = zero dollars. VMware Server cost = zero dollars.
VMware(R) Workstation cost = under $175. (greater flexibility, plus can build VMware instances that can be run by VMware Player or VMware Server).

Both are fully supported under current releases of MS Windows and both support running RHEL as a guest OS on MS Windows host.
(They also support the reverse, running on Linux host with MS Windows guest -- I use this method for MS Windows development at home).

Need a test environment in addition to the build environment? It's just another VMware instance of a Linux guest.

And you can backup/restore the set of files that make up a VMware instance (make sure the instance is shut down first :-)
if you want to try out a different set of packages w/o disturbing the current set.
Easy backup = drag/drop files from host system to a USB-attached hard drive.


Host: MS Windows (or Linux) w/ VMware Player, VMware Server, or VMware Workstation
	Guest 1: build system running old (or new) RHEL or CentOS Linux
	Guest 2: test system running new RHEL or CentOS Linux

plus a shared host directory accessible by both guests to dropoff/pickup the RPMs
(or just SFTP between the two Linux virtual machines)
(if you needed to split the CPU/disk load, you could use two host servers instead, each running one VMware instance of Linux).

--
Cheers!

Merka Phoenix
Sr. Systems Integrator
Merka Associates

Std disclaimer here about: "Views expressed herein are not necessarily those of my employer or my client(s)" :)
(and none of the companies mentioned paid me anything to mention their products, nor do I own any of their stock)

VMware site: http://www.vmware.com/ 
and downloads here: http://downloads.vmware.com/d/info/desktop_downloads/vmware_player/3_0

Linux is a registered trademark of Linus Torvalds.
RED HAT is a registered trademark of Red Hat, Inc. in the United States and other countries.
VMware is a registered trademark of VMware, Inc. in the United States and/or other jurisdictions.  
All other trademarks and trade names are the property of their respective holders.