Message-ID: <451B22AC.5010303@cygwin.com>
Date: Wed, 27 Sep 2006 21:17:32 -0400
From: "Larry Hall (Cygwin)" <reply-to-list-only-lh AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060727 Fedora/1.5.0.5-1.fc4.remi Thunderbird/1.5.0.5 Mnenhy/0.7.4.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Bash 3.1.17(8) CR/LF problem
References: <860934040609271706x2dfcab4fr37a6b11aac9b7f03 AT mail DOT gmail DOT com>
In-Reply-To: <860934040609271706x2dfcab4fr37a6b11aac9b7f03@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Malcolm Nixon wrote:
> Larry Hall (Cygwin) wrote:
>> But what you've described so far isn't adding up and my guess is
>> you're going to have to offer a more convincing argument based
>> on detailed facts relevant to the problem you're having to sway
>> the hearts and minds of those who do the work.
> 
> I guess I have been somewhat vague, so here's about as specific
> as I can get without bumping into NDA issues.
> 
> The customer in question has a project they compile using multiple
> tool chains. Some just for linting, some for debugging/unit testing,
> some for actual end-product release. The targets in question are:
> Visual C++ 6.0, Visual C++ 8.0, SPLint, GCC, ARM Developer
> Suite, RealView Developer Suite, GreenHill.
> 
>> From the vantage point of a developer, they:
>  1) Construct a sandbox in an arbitrary directory on their hard drive.
>  2) Start a Cygwin bash prompt.
>  3) Run a build.sh script at the root of the sandbox.
> 
> Then 'voila' everything works. The 'voila' masks using Bakefile
> (bakefile.sourceforge.net) to generate project files and makefiles
> for all of the targets; using Doxygen to generate source level
> documentation; building the makefiles with make; and the project
> files with the appropriate tools.
> 
> The power of this approach is:
>   * The user can get their sandbox anywhere, not just to a specific
>     text-mode mount point.
>   * The user is free to edit the source files in whatever Windows
>     editor they choose.
>   * The user may open the Project files in the appropriate IDE.
>     Note: We're probably going to be adding Eclipse soon ;-)
>   * The development sources are also the build sources used by
>     cygwin, so builds against all targets can be performed without
>     checking back in to perforce.
> 
> Unfortunately most of the developers only know how to run that root
> build.sh script (with a few different command line arguments).
> They're not converse enough with Cygwin to construct a text-mode
> mount point before doing the fetch from source-control.
> 
> The fix I will probably end up falling back on is to mark those Bash
> scripts as Binary for Perforce so they don't undergo translation in
> the act of fetching. This unfortunately means that merging script
> changes is going to be extremely problematic.
> 
> So to run through the current list of proposed fixes:
> - Change just the Bash scripts to use <LF>:
>      Perforce translates them back.
> - Create text mount points for the sand boxes:
>      The developers grab sandboxes all over the disk.
> - Force <LF> mode for all files in Perforce:
>      The Windows IDEs and editors the developers use then fail.
> - Run d2u on the scripts:
>      There are enough scripts to change that I'd need to write a
>      Bash script to fix the Bash scripts. Chicken != Egg.
>      Additionally those changes would screw with Perforce.
> 
> The fix must be something that having an untrained developer
> merely getting a new sandbox is enough. At this time setting
> the scripts to Binary in Perforce is the only one that meets
> this requirement.


Some other ideas:

- Put the top-level build script (or create a new one) into a set
   location in a binary mount.  It would take the directory name
   for the new tree, mount it properly and kick off the Perforce
   pull/update.  You could even hook this up as a shell command
   so that users could invoke it on the directory they want. ;-)
   This should be a simple build script that wouldn't change much.
   Also, since it's always possible to pull a previous version to
   disk, you can use Cygwin or other tools to do diffs when needed,
   if you can't get Perforce to do them for you in binary mode.

- "mount -ct /cygdrive".  Now everything other than the default
   Cygwin installation directory and '/usr/lib' and '/usr/bin'
   are text mounts to Cygwin tools.  Users can make their installation
   anywhere outside of these three locations (which don't make much
   sense for Perforce source trees anyway).  No mess.  No fuss.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

--
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/