[SCM] Samba Shared Repository - branch master updated

Jeremy Allison jra at samba.org
Fri Jun 12 23:33:04 UTC 2020


The branch, master has been updated
       via  4aba00b554f doc: Add markup to README.Coding for samba wiki links
       via  c433e177249 docs: protocolfreedom.org is no longer
       via  ad7639a1279 Remove outdated install_with_python.sh
       via  5ad6dcf2ec0 docs: Point to wiki Contribute page rather than samba-technical
       via  6446e86b54c build: Put the note from the bottom of the old BUILD_SYSTEMS.txt somewhere useful
       via  bfe4e84bb91 docs: Remove the statement about why we moved to Waf
       via  8a08dc0074d Update README.md with more up to date information
       via  07856586073 Update README.contributing to point to new Contributing wiki page
      from  7655a0298e5 db-glue.c: set forwardable flag on cross-realm tgt tickets

https://git.samba.org/?p=samba.git;a=shortlog;h=master


- Log -----------------------------------------------------------------
commit 4aba00b554f88a8efd2e08ccdfbc259543ffdd98
Author: David Mulder <dmulder at suse.com>
Date:   Fri Jun 12 15:15:04 2020 -0600

    doc: Add markup to README.Coding for samba wiki links
    
    Adding markup to the README.Coding allows us to
    link to sections of the document from the samba
    wiki and prevents documentation duplication.
    
    Signed-off-by: David Mulder <dmulder at suse.com>
    Reviewed-by: Andrew Bartlett <abartlet at samba.org>
    Reviewed-by: Jeremy Allison <jra at samba.org>
    
    Autobuild-User(master): Jeremy Allison <jra at samba.org>
    Autobuild-Date(master): Fri Jun 12 23:32:30 UTC 2020 on sn-devel-184

commit c433e17724996a0d2aae5a451627b8029ff0c187
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Wed Jun 3 16:18:36 2020 +1200

    docs: protocolfreedom.org is no longer
    
    It is just a random spam site now
    
    Signed-off-by: Andrew Bartlett <abartlet at samba.org>
    Reviewed-by: Jeremy Allison <jra at samba.org>

commit ad7639a12796e269c130ead21dc2299ae640c586
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Wed Jun 3 16:16:49 2020 +1200

    Remove outdated install_with_python.sh
    
    This was a cludge to help get past the need for Python on
    the Samba build farm in particular.  We now need Python3
    by default so clearly this has not been used in quite some
    time so is safe to remove.
    
    Signed-off-by: Andrew Bartlett <abartlet at samba.org>
    Reviewed-by: Jeremy Allison <jra at samba.org>

commit 5ad6dcf2ec0fa9752eb912a994503deaf8686423
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Wed Jun 3 16:10:50 2020 +1200

    docs: Point to wiki Contribute page rather than samba-technical
    
    Signed-off-by: Andrew Bartlett <abartlet at samba.org>
    Reviewed-by: Jeremy Allison <jra at samba.org>

commit 6446e86b54ccdc6da397487b850832727cbb69c1
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Wed Jun 3 16:06:34 2020 +1200

    build: Put the note from the bottom of the old BUILD_SYSTEMS.txt somewhere useful
    
    This statement on how we handle --with options is best placed near where
    the options are set, so developers see it when trying to choose the
    correct thing to do.
    
    Signed-off-by: Andrew Bartlett <abartlet at samba.org>
    Reviewed-by: Jeremy Allison <jra at samba.org>

commit bfe4e84bb917e00c8b8d9e6db40527378e8bfb97
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Wed Jun 3 15:51:48 2020 +1200

    docs: Remove the statement about why we moved to Waf
    
    This is not important for new users or developers, and has little useful information
    
    Signed-off-by: Andrew Bartlett <abartlet at samba.org>
    Reviewed-by: Jeremy Allison <jra at samba.org>

commit 8a08dc0074de2e85058849e81524eb5e73dfe7e6
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Wed Jun 3 15:50:28 2020 +1200

    Update README.md with more up to date information
    
    In particular, point to the new Contribute page on the wiki
    
    Signed-off-by: Andrew Bartlett <abartlet at samba.org>
    Reviewed-by: Jeremy Allison <jra at samba.org>

commit 07856586073572fb2c3a56f2e5e4da3bd4e4daf2
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Wed Jun 3 15:43:28 2020 +1200

    Update README.contributing to point to new Contributing wiki page
    
    Signed-off-by: Andrew Bartlett <abartlet at samba.org>
    Reviewed-by: Jeremy Allison <jra at samba.org>

-----------------------------------------------------------------------

Summary of changes:
 BUILD_SYSTEMS.txt                  |  80 -------------------
 PFIF.txt                           |   3 +-
 README.Coding => README.Coding.md  | 158 ++++++++++++++++++++++---------------
 README.contributing                |  15 ++--
 README.md                          |  53 ++++---------
 buildtools/wafsamba/samba_utils.py |   3 +
 examples/README                    |   2 +-
 install_with_python.sh             |  63 ---------------
 source3/wscript                    |  21 +++++
 wscript                            |  19 +++++
 10 files changed, 159 insertions(+), 258 deletions(-)
 delete mode 100644 BUILD_SYSTEMS.txt
 rename README.Coding => README.Coding.md (84%)
 delete mode 100755 install_with_python.sh


Changeset truncated at 500 lines:

diff --git a/BUILD_SYSTEMS.txt b/BUILD_SYSTEMS.txt
deleted file mode 100644
index f1d1ce393fb..00000000000
--- a/BUILD_SYSTEMS.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-BUILDING SAMBA 4.0
-===================================
-
-The waf build
--------------
-
-Samba 4.0 ships with a new build system, based on waf.  A background to
-this build system can be found at https://wiki.samba.org/index.php/Waf
-
-This is the build system that is used when you run ./configure && make
-in the top level of a Samba 4.0 release tree.
-
-For the vast majority of our users, this is the build system you should
-use.  It supports parallel and incremental builds, and builds the whole
-Samba suite, the file server, the print server, the NT4 domain
-controller, winbind, the AD Domain Controller, the client libraries and
-the python libraries.  
-
-A key feature for many of our distributors and OEMs is that despite the
-range of additional features, the resulting binaries and libraries are
-substantially smaller, because we use shared libraries extensively. 
-
-For distributions that have a requirement to use the system-supplied
-Kerberos library, we support building against a Heimdal or system MIT
-Kerberos library, provided the version is recent enough (otherwise we
-will use our internal version of Heimdal).  Please note that builds
-with MIT krb5 support will not have AD DC features.
-
-Where we provide a tool under a name that was used in Samba 3.x, it
-continues to behave in the same way it always has.  This will ensure
-that our change in build system does not impact on our user's ability
-to use Samba as they always have.
-
-For developers, this build system backs a comprehensive 'make test',
-which provides code coverage of around 48% of our code by line:
-https://build.samba.org/lcov/data/coverage/samba_4_0_test/
-
-This build system also implements important features such as ABI
-checking (which protects you as users from accidental changes to our
-published libraries), symbol versions and dependency checked incremental
-rebuilds after header-file changes. 
-
-The waf build also assists developers by providing fully-linked binaries
-that run from bin/ without needing to set LD_LIBRARY_PATH. 
-
-For users who do not have python installed on their systems, we provide
-a install_with_python.sh script, which will install a local copy of
-python sufficient to run the build system, without impacting on the rest
-of the system.  
-
-Within this requirement, we expect that this build will run on all our
-supported platforms, and will actively deal with any portability issues
-that users can bring to our attention. 
-
-For all these reasons, we highly recommend this new build system to all
-our users, for whatever purpose you want to put Samba to.
-
-The autoconf build
-------------------
-
-The autoconf build was removed in Samba 4.1.  If you have tried and
-failed to use our waf build system, you may wish to use the latest
-supported 4.0 release instead, while we address your use case.
-
-Optional Libraries
-------------------
-
-To assist users and distributors to build Samba with the full feature
-set, the build system will abort if our dependent libraries and their
-header files are not found on the target system.  This will mean for
-example, that xattr, acl and ldap headers must be installed for the
-default build to complete.  The configure system will check for these
-headers, and the error message will indicate the option (such as
---without-acl-support) that can be specified to skip this requirement.
-
-This will assist users and in particular distributors in building fully
-functional packages, while allowing those on systems truly without these
-facilities to continue to build Samba after careful consideration.
-
-This feature is not currently supported for xattr.
diff --git a/PFIF.txt b/PFIF.txt
index 09f1458e441..ab28c563332 100644
--- a/PFIF.txt
+++ b/PFIF.txt
@@ -2,6 +2,5 @@ This code was developed in participation with the Protocol Freedom
 Information Foundation.
 
 Please see 
-  http://protocolfreedom.org/ and
-  http://samba.org/samba/PFIF/ 
+  https://www.samba.org/samba/PFIF/
 for more details.
diff --git a/README.Coding b/README.Coding.md
similarity index 84%
rename from README.Coding
rename to README.Coding.md
index ac9bcd43065..914e3573ad4 100644
--- a/README.Coding
+++ b/README.Coding.md
@@ -1,11 +1,6 @@
-Coding conventions in the Samba tree
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+# Coding conventions in the Samba tree
 
-.. contents::
-
-===========
-Quick Start
-===========
+## Quick Start
 
 Coding style guidelines are about reducing the number of unnecessary
 reformatting patches and making things easier for developers to work
@@ -21,10 +16,10 @@ Documentation/CodingStyle in the kernel source tree). This closely matches
 what most Samba developers use already anyways, with a few exceptions as
 mentioned below.
 
-The coding style for Python code is documented in PEP8,
-https://www.python.org/dev/peps/pep-0008/. New Python code should be compatible
+The coding style for Python code is documented in
+[PEP8](https://www.python.org/dev/peps/pep-0008/). New Python code should be compatible
 with Python 2.6, 2.7, and Python 3.4 onwards. This means using Python 3 syntax
-with the appropriate 'from __future__' imports.
+with the appropriate `from __future__` imports.
 
 But to save you the trouble of reading the Linux kernel style guide, here
 are the highlights.
@@ -32,49 +27,52 @@ are the highlights.
 * Maximum Line Width is 80 Characters
   The reason is not about people with low-res screens but rather sticking
   to 80 columns prevents you from easily nesting more than one level of
-  if statements or other code blocks.  Use source3/script/count_80_col.pl
+  if statements or other code blocks.  Use [source3/script/count_80_col.pl](source3/script/count_80_col.pl)
   to check your changes.
 
 * Use 8 Space Tabs to Indent
   No whitespace fillers.
 
 * No Trailing Whitespace
-  Use source3/script/strip_trail_ws.pl to clean up your files before
+  Use [source3/script/strip_trail_ws.pl](source3/script/strip_trail_ws.pl) to clean up your files before
   committing.
 
 * Follow the K&R guidelines.  We won't go through all of them here. Do you
   have a copy of "The C Programming Language" anyways right? You can also use
-  the format_indent.sh script found in source3/script/ if all else fails.
+  the [format_indent.sh script found in source3/script/](source3/script/format_indent.sh) if all else fails.
+
 
 
+## Editor Hints
 
-============
-Editor Hints
-============
+### Emacs
 
-Emacs
------
 Add the follow to your $HOME/.emacs file:
 
+```
   (add-hook 'c-mode-hook
 	(lambda ()
 		(c-set-style "linux")
 		(c-toggle-auto-state)))
+```
 
 
-Vi
---
+### Vi
+
 (Thanks to SATOH Fumiyasu <fumiyas at osstech.jp> for these hints):
 
 For the basic vi editor included with all variants of \*nix, add the
 following to $HOME/.exrc:
 
+```
   set tabstop=8
   set shiftwidth=8
+```
 
 For Vim, the following settings in $HOME/.vimrc will also deal with
 displaying trailing whitespace:
 
+```
   if has("syntax") && (&t_Co > 2 || has("gui_running"))
 	syntax on
 	function! ActivateInvisibleCharIndicator()
@@ -89,9 +87,11 @@ displaying trailing whitespace:
   " highlight overly long lines same as TODOs.
   set textwidth=80
   autocmd BufNewFile,BufRead *.c,*.h exec 'match Todo /\%>' . &textwidth . 'v.\+/'
+```
+
+### clang-format
 
-clang-format
-------------
+```
 BasedOnStyle: LLVM
 IndentWidth: 8
 UseTab: true
@@ -101,14 +101,12 @@ IndentCaseLabels: false
 BinPackParameters: false
 BinPackArguments: false
 SortIncludes: false
+```
 
 
-=========================
-FAQ & Statement Reference
-=========================
+## FAQ & Statement Reference
 
-Comments
---------
+### Comments
 
 Comments should always use the standard C syntax.  C++
 style comments are not currently allowed.
@@ -120,6 +118,7 @@ of multiple following code blocks.
 
 This is good:
 
+```
 	...
 	int i;
 
@@ -155,9 +154,11 @@ This is good:
 	 * @return              0 on success and -1 on error.
 	 */
 	int example(int param1, int *result1);
+```
 
 This is bad:
 
+```
 	...
 	int i;
 	/*
@@ -185,9 +186,9 @@ This is bad:
 	/*
 	 * This is a multi line comment,
 	 * with some more words...*/
+```
 
-Indention & Whitespace & 80 columns
------------------------------------
+### Indention & Whitespace & 80 columns
 
 To avoid confusion, indentations have to be tabs with length 8 (not 8
 ' ' characters).  When wrapping parameters for function calls,
@@ -195,8 +196,10 @@ align the parameter list with the first parameter on the previous line.
 Use tabs to get as close as possible and then fill in the final 7
 characters or less with whitespace.  For example,
 
+```
 	var1 = foo(arg1, arg2,
 		   arg3);
+```
 
 The previous example is intended to illustrate alignment of function
 parameters across lines and not as encourage for gratuitous line
@@ -210,18 +213,21 @@ line. The rationale is that if there are many parameters, each one
 should be on its own line to make tracking interface changes easier.
 
 
-If, switch, & Code blocks
--------------------------
+## If, switch, & Code blocks
 
-Always follow an 'if' keyword with a space but don't include additional
+Always follow an `if` keyword with a space but don't include additional
 spaces following or preceding the parentheses in the conditional.
 This is good:
 
+```
 	if (x == 1)
+```
 
 This is bad:
 
+```
 	if ( x == 1 )
+```
 
 Yes we have a lot of code that uses the second form and we are trying
 to clean it up without being overly intrusive.
@@ -230,7 +236,7 @@ Note that this is a rule about parentheses following keywords and not
 functions.  Don't insert a space between the name and left parentheses when
 invoking functions.
 
-Braces for code blocks used by for, if, switch, while, do..while, etc.
+Braces for code blocks used by `for`, `if`, `switch`, `while`, `do..while`, etc.
 should begin on the same line as the statement keyword and end on a line
 of their own. You should always include braces, even if the block only
 contains one statement.  NOTE: Functions are different and the beginning left
@@ -240,11 +246,12 @@ If the beginning statement has to be broken across lines due to length,
 the beginning brace should be on a line of its own.
 
 The exception to the ending rule is when the closing brace is followed by
-another language keyword such as else or the closing while in a do..while
+another language keyword such as else or the closing while in a `do..while`
 loop.
 
 Good examples:
 
+```
 	if (x == 1) {
 		printf("good\n");
 	}
@@ -263,9 +270,11 @@ Good examples:
 	do {
 		printf("also good\n");
 	} while (1);
+```
 
 Bad examples:
 
+```
 	while (1)
 	{
 		print("I'm in a loop!\n"); }
@@ -279,12 +288,12 @@ Bad examples:
 
 	if (i < 10)
 		print("I should be in braces.\n");
+```
 
 
-Goto
-----
+### Goto
 
-While many people have been academically taught that "goto"s are
+While many people have been academically taught that `goto`s are
 fundamentally evil, they can greatly enhance readability and reduce memory
 leaks when used as the single exit point from a function. But in no Samba
 world what so ever is a goto outside of a function or block of code a good
@@ -292,6 +301,7 @@ idea.
 
 Good Examples:
 
+```
 	int function foo(int y)
 	{
 		int *z = NULL;
@@ -314,10 +324,10 @@ Good Examples:
 
 		return ret;
 	}
+```
 
 
-Primitive Data Types
---------------------
+### Primitive Data Types
 
 Samba has large amounts of historical code which makes use of data types
 commonly supported by the C99 standard. However, at the time such types
@@ -326,31 +336,31 @@ were forced to provide their own.  Now that these types are guaranteed to
 be available either as part of the compiler C99 support or from
 lib/replace/, new code should adhere to the following conventions:
 
-  * Booleans are of type "bool" (not BOOL)
-  * Boolean values are "true" and "false" (not True or False)
-  * Exact width integers are of type [u]int[8|16|32|64]_t
+  * Booleans are of type `bool` (not `BOOL`)
+  * Boolean values are `true` and `false` (not `True` or `False`)
+  * Exact width integers are of type `[u]int[8|16|32|64]_t`
 
 Most of the time a good name for a boolean variable is 'ok'. Here is an
 example we often use:
 
+```
 	bool ok;
 
 	ok = foo();
 	if (!ok) {
 		/* do something */
 	}
+```
 
 It makes the code more readable and is easy to debug.
 
-Typedefs
---------
+### Typedefs
 
-Samba tries to avoid "typedef struct { .. } x_t;" so we do always try to use
-"struct x { .. };". We know there are still such typedefs in the code,
+Samba tries to avoid `typedef struct { .. } x_t;` so we do always try to use
+`struct x { .. };`. We know there are still such typedefs in the code,
 but for new code, please don't do that anymore.
 
-Initialize pointers
--------------------
+### Initialize pointers
 
 All pointer variables MUST be initialized to NULL. History has
 demonstrated that uninitialized pointer variables have lead to various
@@ -362,6 +372,7 @@ instructions sequence may change over time.
 
 Good Example:
 
+```
 	char *pointer1 = NULL;
 	char *pointer2 = NULL;
 
@@ -370,9 +381,11 @@ Good Example:
 	...
 
 	pointer1 = some_func1();
+```
 
 Bad Example:
 
+```
 	char *pointer1;
 	char *pointer2;
 
@@ -381,9 +394,9 @@ Bad Example:
 	...
 
 	pointer1 = some_func1();
+```
 
-Make use of helper variables
-----------------------------
+### Make use of helper variables
 
 Please try to avoid passing function calls as function parameters
 in new code. This makes the code much easier to read and
@@ -391,6 +404,7 @@ it's also easier to use the "step" command within gdb.
 
 Good Example:
 
+```
 	char *name = NULL;
 	int ret;
 
@@ -401,12 +415,15 @@ Good Example:
 
 	ret = some_function_my_name(name);
 	...
+```
 
 
 Bad Example:
 
+```
 	ret = some_function_my_name(get_some_name());
 	...
+```
 
 Please try to avoid passing function return values to if- or
 while-conditions. The reason for this is better handling of code under a
@@ -414,23 +431,29 @@ debugger.
 
 Good example:
 
+```
 	x = malloc(sizeof(short)*10);
 	if (x == NULL) {
 		fprintf(stderr, "Unable to alloc memory!\n");
 	}
+```
 
 Bad example:
 
+```
 	if ((x = malloc(sizeof(short)*10)) == NULL ) {
 		fprintf(stderr, "Unable to alloc memory!\n");
 	}
+```
 
 There are exceptions to this rule. One example is walking a data structure in
 an iterator style:
 
+```
 	while ((opt = poptGetNextOpt(pc)) != -1) {
 		   ... do something with opt ...
 	}
+```
 
 Another exception: DBG messages for example printing a SID or a GUID:
 Here we don't expect any surprise from the printing functions, and the
@@ -439,6 +462,7 @@ rarely exists for this particular use case, and we gain some
 efficiency because the DBG_ macros don't evaluate their arguments if
 the debuglevel is not high enough.
 
+```


-- 
Samba Shared Repository



More information about the samba-cvs mailing list