[CF-Devel] SDL client and debian/linux

[Mark Wedel]

Michael Toennies wrote:
>
     
     
     >
     
      Hm, when you guys has tried it with the ^M inside and you don't has tools
     
     >
     
      to handle it, you has problems.
     
     
 The issue isn't what was the right thing that should have been done in the
history of computers and OS's, as that is something no one can really change (or
most people are not willing to change OS's, and even if it was, then you get
into what OS is the right OS).

 Certainly there are ways to strip the ^M out of the files.  The issue here is
that it is more a bother.  Simply put, if the code is a pain for people to use
(because of the ^M's, or it uses non standard extensions, or whatever else),
people will probably not work on it.  You will have to ask yourself if that is
your intended goal or not.


>
     
      There are more bad points, where unix really sucks when it tries to do other
     
     >
     
      things then
     
     >
     
      the standard ones - cvs is totally crappy in working with windows ascii
     
     >
     
      files or binaries.
     
     >
     
      Notice, that in the real big world (banks and other big data handling
     
     >
     
      companies) most count cvs
     
     >
     
      as "not useful for professional use".
     
     
 I think that is a spurious argument.  Many big instutions consider open source
programs in general not useful for professional use.  Yet that is what we are
doing here.  Should we pack it all up because of that?


>
     
     
     >
     
      Btw, under windows, every slightly good shareware tool (text editor or
     
     >
     
      compiler) can handle all
     
     >
     
      this stuff. The point is, that i DON'T SEE in windows any difference in
     
     >
     
      editor or VC between a
     
     >
     
      windows or unix file - they handled 100% in the right way. You can even mix
     
     >
     
      unix and windows text-
     
     >
     
      it will shown right.
     
     
 The ^M is more of an issue of just being obnoxious than anything serious.

 The // issue is serious - simply put it is not legal ANSI C code.  Sure, people
can go off and find compilers that may take it, but if I have a working ANSI C
compiler on my system yet can't compile because of special extensions, I think
it is fair to complain about the code.  And in fact, at my old company
(pyramid), there was no option except to use the C compiler they provided, as
GCC had not been ported.  And the pyramid C compiler was strictly ansi
conforming, hence various changes so that function parameters did not match the
same as typedef structures, as that is illegal, but most compilers don't have a
problem with.

 AT some level, you can write whatever you want, and if its something seperate,
like the SDL client, not a big deal.  Yet at the same time, you should then not
be surprised that no one else is working on it when they can't even compile it. 
I'm willing to spend a few minutes fixing a configuration file, but I'm not
willing to spend a bunch of time fixing up non standard code just to see how it
works.  And I think others may have similar feelings.

>
     
     
     >
     
      Ok, we should set for the source there some rules. In all ways, this above
     
     >
     
      is pur trivial.
     
     
 There are some in doc/programming_guide.  A couple points from it:

9) Assume all names use one namespace.  For example, if there is a
struct called spell, don't make the name of an optional parameter spell.
This will break on ANSI C compilers that follow the spec strictly
(gcc does not, even with -strict -ansi)

10) As a followup on 9 above, don't use nonstandard gcc extensions
(// for comment lines, ability to nest functions, declare arrays with
variable bounds, etc.)  Likewise, don't use special system functions - don't
assume the target system will be bsd or svr4 - if using a potentially non
standard function, add checks in the autoconf script and include a version
of the function in case it is not on that system.  They key word here is
portability - don't assume everyone else has the same system as you do.

>
     
     
     >
     
      To the source - remember i hacked the flat mode in 4 hours. And some is
     
     >
     
      ripped from dx client.
     
     >
     
      For other system you don't have to compile it - you have to implement it.
     
     >
     
      This is the stage the source go to alpha - is even pur work source yet.
     
     >
     
      So don't expect a non warning/error compiling in the first steps.
     
     
 That is perfectly fair.  In that case, just giving some warning like 'this is
experimental, it may not work, let me know of any bugs'.  It is often very
difficult to know the status of code without it explicitly being said - I always
had a problem when people posted patches to the mailing list, and I learned that
I had to explicity ask the person posting the patch if they were intending for
that patch to get included in the source, or if that was an 'alpha' level patch
that they put out for other people to test.

 Do note that modification to the CVS repository is meant to at least be alpha+
level code (ie, it compiles, is portable, and has gone through at least some
testing).  But if your making your own code, putting it up someplace for people
to download, it seems people deserve what they get (but you may want to give
better status of the code).  IMO, such an approach may be better then committing
potentially buggy code into CVS, OTOH, it may not get used as much.

 I will say that if you do look at committing such code into CVS, look at the
tagging facility - tagging a distribution then allows people to easily go back
to code prior to the changes just be giving the right tag (eg, cvs tag
snapshot_2001_11_03 would then allow anyone to easily get all the files as they
were at the time of the snapshot - in the above case, I used a date, typically,
someting more descriptive like 'pre_new_iso_code' or something would probably be
better.