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


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/


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