X-Git-Url: http://wien.tomnetworks.com/gitweb/?a=blobdiff_plain;f=mcs%2Fclass%2FREADME;h=efebe9ad5a9acc314ec75efbb1ffda5a9fb1ba7f;hb=c4c9b306caed8e19396729e62ea48119bdb7e5d8;hp=fa83397fdf41f6a023d49b44d6559938df4917d6;hpb=14b9548f8a6f48b942e0b493dcc557afacd17326;p=mono.git diff --git a/mcs/class/README b/mcs/class/README index fa83397fdf4..efebe9ad5a9 100644 --- a/mcs/class/README +++ b/mcs/class/README @@ -6,24 +6,12 @@ divide the code based on the namespace they implement. In addition, each assembly directory contains a Test directory that holds the NUnit tests for that assembly. -The nant build file for an assembly creates two versions of the dll for that -assembly. One version is a "full" dll. The full dll contains (almost) all -of the classes, regardless of how complete the classes are. The name of this -dll is the normal name you would expect, like "corlib.dll" or "System.dll". -These full dll's are created in the /mcs/class/lib directory. - -The other dll which is built is a "restricted" dll. The restricted dll -omits incomplete classes that would prevent the NUnit testrunner from actually -running the tests. These restricted dll's are created in the Test directory -of their respective assembly and named with a "_res" suffix. So, for example, -the NUnit-testable dll for corlib is /mcs/class/corlib/Test/corlib_res.dll. - -The final dll which is built is the one which houses the actual NUnit tests. -This dll is built from all of the classes in the Test directory and below, and -is named with a "_test" suffix. So, for example, the NUnit tests for corlib -are in /mcs/class/corlib/Test/corlib_test.dll. This dll is also linked with -the restricted dll found in the same directory. +We use a new build system which is described by various README files +in mcs/build +The build process typically builds an assembly, but in some cases it +also builds special versions of the assemblies intended to be used for +testing. * Missing implementation bits @@ -37,11 +25,24 @@ the restricted dll found in the same directory. throw new NotImplementedException (); } -* Supporting both .NET 1.1 and .NET 1.0 builds + Ideally, write a human description of the reason why there is + a MonoTODO, this will be useful in the future for our + automated tools that can assist in developers porting their + code. + + Do not use MonoTODO attributes for reminding yourself of + internal changes that must be done. Use FIXMEs or other kinds + of comments in the source code for that purpose, and if the + problem requires to be followed up on, file a bug. + +* Supporting .NET 1.2, .NET 1.1 and .NET 1.0 builds - Use #ifdef NET_1_1 for code that should only be included for - a .NET 1.1 build, and NET_1_0 for code that should only be included - for a 1.0 build. + The defines NET_1_1 and NET_2_0 are used to include + features. When NET_2_0 is defined, it also implies that the + NET_1_1 is defined. + + To have code which is only available in an old version, use ONLY_1_0, + ONLY_1_1 * Tagging buggy code @@ -233,6 +234,45 @@ the restricted dll found in the same directory. void Method (string lpstrArgument) void Method (string my_string) + * Empty methods: They should have the body of code using two + lines, in consistency with the rest: + + good: + void EmptyMethod () + { + } + + bad: + void EmptyMethod () {} + + void EmptyMethod () + {} + + * Line length: The line length for C# source code is 134 columns. + + + If your function declaration arguments go beyond + this point, please align your arguments to match the + opening brace, like this: + + void Function (int arg, string argb, + int argc) + { + } + + When invoking functions, the rule is different, the + arguments are not aligned with the previous + argument, instead they begin at the tabbed position, + like this: + + void M () + { + MethodCall ("Very long string that will force", + "Next argument on the 8-tab pos", + "Just like this one") + + } + Here are a couple of examples: class X : Y { @@ -280,4 +320,4 @@ class X : Y { } } } - \ No newline at end of file +