X-Spam-Check-By:	sourceware.org
Message-ID:	<43CE95A1.3914127C@dessent.net>
Date:	Wed, 18 Jan 2006 11:23:13 -0800
From:	Brian Dessent <brian AT dessent DOT net>
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Building Cygwin from CVS
References:	<43CE88C6 DOT 3070009 AT hones DOT org DOT uk> <43CE8CF3 DOT 375BB3B3 AT dessent DOT net> <43CE92A6 DOT 7010608 AT hones DOT org DOT uk>
X-IsSubscribed:	yes
Reply-To:	cygwin AT cygwin DOT com
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Cliff Hones wrote:

> Well, maybe it is a timestamp problem, but the make did fail trying to regenerate
> devices.cc using the gendevices script.  After I'd installed cocom it worked,
> and overwrote devices.cc in the src/winsup/cygwin directory.  

That does sound like a timestamp issue then.  I suppose you could "touch
-r devices.in devices.cc" after a checkout.  Gcc uses a script
contrib/update_gcc to deal with these inadequecies of version control.

> This seems
> wrong by the way - a separated build shouldn't alter anything in src.

Well, it's a generated file, just like configure.  There are of course
many schools of thought on how to deal with generated files in CVS, but
most people seem to agree that keeping them in the repository is
generally OK since end users can build from CVS without needing the
correct version of the autotools installed, for instance.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -