X-Spam-Check-By: sourceware.org Message-ID: <43CE95A1.3914127C@dessent.net> Date: Wed, 18 Jan 2006 11:23:13 -0800 From: Brian Dessent 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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/