This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bash 3.1.17(8) CR/LF problem


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]