Message-ID: <860934040609271706x2dfcab4fr37a6b11aac9b7f03@mail.gmail.com>
Date: Wed, 27 Sep 2006 17:06:53 -0700
From: "Malcolm Nixon" <malcolm DOT nixon AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Bash 3.1.17(8) CR/LF problem
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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

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.

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