In the course of putting together an MSVC build for Csound I have encountered inconsistent tabs/spaces in SConstruct and other files, inconsistent Windows/OS X/Unix line endings, and so on.

Please, can we agree on the following standards for source code editing?

-- All line endings should be Unix line endings (one linefeed, no carriage return).

-- When you inspect whitespace in a source file, you should always see 1 tab character every 4 spaces, never any blocks of spaces. (Actually it can be every 8 spaces, but it is important to use tabs not spaces for indenting.)

A number of things broke in my build and John ffitch's build related to these issues: SConstruct failed due to mixture of tabs and spaces for Python indenting, and a number of files had OS X line endings and would not build with MSVC at all until I reformatted them.

It is important to be consistent in a cross-platform project, and Posix/GNU is a reasonable standard.

Please let us know if there are questions or objections.

Regards,
Mike



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> -- When you inspect whitespace in a source file, you should always
> see 1 tab character every 4 spaces, never any blocks of spaces. (Actually
> it can be every 8 spaces, but it is important to use tabs not spaces for
> indenting.)
> 
> A number of things broke in my build and John ffitch's build related to
> these issues: SConstruct failed due to mixture of tabs and spaces for Python
> indenting,

Quite honstly, asking *people* to keep an eye on things which are not easily
visible (like spaces, tabs and line endings) is doomed to failure.

However, there are solutions. There is a Python tool called tabnanny:

    http://svn.python.org/projects/python/trunk/Lib/tabnanny.py

which checks Python source for indentation screwups. Similarly, it would
be trivial to write something that converts Mac and windows line endings
to Unix ones (or even find an existing one).

Then, when you have these two tools, you make running those are part of
the build or CVS commit process (ie a commit cannot go ahead untill those
two tools have validated the source that is being committed) and viola,
problem fixed, once and for all.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Web (hosting), security and high-performance computing are the
three areas where Linux has more strength." --
Bob Muglia, senior VP in charge of Windows Server development.
http://news.com.com/Microsoft+targets+Apache+Web+server/2100-1010_3-5735805.html

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

In my emacs settings tabs and spaces look different; I also regularly
check sources for tabs.  M-x untabify-buffer then fixes it.
==John ffitch

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net