DOC: Update CONTRIBUTING (Python virtualenv | SWIG | Minimal CMAKE bu…

…ild | headers)

CONTRIBUTING.md

@@ -1,66 +1,110 @@
-Setting development environment (Unix)
-======================================
+# Setting development environment (Unix)
+
+## Build SWIG
+
+SWIG (https://swig.org/) is required to compile GDAL with other programming languages, such as Python.
+
+> **Note**
+> SWIG version 4.0.2 is required.
+
+Set the installation path:
+
+```bash
+export SWIG_PREFIX=/path/to/install
+
+```
+
+Install SWIG from source:
+
+```bash
+export SWIG_VERSION=4.0.2
+mkdir /tmp/swig/
+cd /tmp/swig/
+wget https://sourceforge.net/projects/swig/files/swig/swig-${SWIG_VERSION}/swig-${SWIG_VERSION}.tar.gz/download -O swig-${SWIG_VERSION}.tar.gz
+tar xf swig-${SWIG_VERSION}.tar.gz
+cd swig-${SWIG_VERSION}
+./configure --prefix=$SWIG_PREFIX
+make
+make install
+export PATH=$SWIG_PREFIX/bin:$PATH
+```
+
+## Build GDAL: Autotools
 
 Install all required development packages: GNU make, g++, ...
 
 Build:
 
-```
+```bash
 ./autogen.sh
 ./configure --with-python [other options]
 make -j8 -s
 cd apps; make -s test_ogrsf; cd ..
 ```
 
 Run command line utilities (without installing):
-```
+```bash
 . scripts/setdevenv.sh
 gdalinfo --version
 ```
 
 Run autotest suite:
-```
+```bash
 cd autotest
 pip install -r requirements.txt
 pytest
 ```
 
-Setting development environment (CMake, EXPERIMENTAL)
-=====================================================
+## Build GDAL: CMake (EXPERIMENTAL)
 
 Note: CMake builds are EXPERIMENTAL for now.
 
 Install all required development packages: GNU make, g++, ...
 
-Configure and build:
+Setup [Python Virtual environment](https://docs.python.org/3/library/venv.html):
+
+> **Note**
+> Add the [Python_FIND_VIRTUALENV=ONLY](https://gdal.org/build_hints.html#cmdoption-arg-Python_FIND_VIRTUALENV) `cmake` option with a Python virtual environment.
 
+```bash
+python -m venv gdal_venv
+. gdal_venv/bin/activate
+python -m pip install numpy
 ```
+
+Configure and build:
+
+> **Note**
+> For a minimal build, add these options: `GDAL_BUILD_OPTIONAL_DRIVERS=OFF` `OGR_BUILD_OPTIONAL_DRIVERS=OFF`.
+> To enable specific drivers, add `GDAL_ENABLE_DRIVER_<driver_name>=ON` or `OGR_ENABLE_DRIVER_<driver_name>=ON`.
+> See [Selection of Drivers](https://gdal.org/build_hints.html#selection-of-drivers)
+> for more details.
+
+```bash
 mkdir build
 cd build
 cmake .. [options]
-make -j8 -s
+cmake --build . -j$(nproc)
 ```
 
 Run command line utilities (without installing):
-```
+```bash
 . ../scripts/setdevenv.sh
 gdalinfo --version
 ```
 
 Run autotest suite:
-```
-pip install -r ../autotest/requirements.txt
+```bash
+python -m pip install -r ../autotest/requirements.txt
 pytest autotest
 ```
 
-Git workflows with GDAL
-=======================
+# Git workflows with GDAL
 
 This is not a git tutorial or reference manual by any means. This just collects
 a few best practice for git usage for GDAL development.
 
-Commit message
---------------
+## Commit message
 
 Indicate a component name (eg a driver name), a short description and when
 relevant, a reference to a issue (with 'fixes #' if it actually fixes it)
@@ -71,32 +115,29 @@ COMPONENT_NAME: fix bla bla (fixes #1234)
 Details here...
 ```
 
-Initiate your work repository
------------------------------
+## Initiate your work repository
 
 Fork OSGeo/gdal from github UI, and then
-```
+```bash
 git clone https://github.com/OSGeo/gdal
 cd gdal
 git remote add my_user_name [email protected]:my_user_name/gdal.git
 ```
 
-Updating your local master against upstream master
---------------------------------------------------
+## Updating your local master against upstream master
 
-```
+```bash
 git checkout master
 git fetch origin
 # Be careful: this will loose all local changes you might have done now
 git reset --hard origin/master
 ```
 
-Working with a feature branch
------------------------------
+## Working with a feature branch
 
-```
+```bash
 git checkout master
-(potentially update your local master against upstream, as described above)
+# potentially update your local master against upstream, as described above
 git checkout -b my_new_feature_branch
 
 # do work. For example:
@@ -112,8 +153,9 @@ git rebase origin/master
 
 # At end of your work, make sure history is reasonable by folding non
 # significant commits into a consistent set
-git rebase -i master (use 'fixup' for example to merge several commits together,
-and 'reword' to modify commit messages)
+git rebase -i master 
+# use 'fixup' for example to merge several commits together,
+# and 'reword' to modify commit messages
 
 # or alternatively, in case there is a big number of commits and marking
 # all them as 'fixup' is tedious
@@ -133,23 +175,21 @@ commit locally and push. To get a reasonable history, you may need to
 branch with ```git push -f my_user_name my_new_feature_branch```
 
 
-Backporting bugfixes from master to a stable branch
----------------------------------------------------
+## Backporting bugfixes from master to a stable branch
 
-```
+```bash
 git checkout master
 With git log, identify the sha1sum of the commit you want to backport
-git checkout 2.2 (if you want to backport to 2.2)
+git checkout 2.2 # if you want to backport to 2.2
 git pull origin 2.2
-(git checkout -b branch_name: if you intend to submit the backport as a pull request)
+# git checkout -b branch_name  # if you intend to submit the backport as a pull request
 git cherry-pick the_sha1_sum
 git push ...
 ```
 If changes are needed, do them and ```git commit -a --amend```
 
 
-Things you should NOT do
-------------------------
+## Things you should NOT do
 
 (For anyone with push rights to github.com/OSGeo/gdal) Never modify a commit or
 the history of anything that has been