mirror of https://github.com/CGAL/cgal
spell checking by Albert
Sébastien Loriot
parent
70a2ad1fd8
commit
342ded65ef
|
|
@ -13,7 +13,7 @@ You will need the sources for `bzip2` and `zlib` before building boost. They can
|
|||
The full command is
|
||||
`.\b2.exe -s NO_BZIP2=0 -s BZIP2_SOURCE="<bzip2_root_dir>" -s ZLIB_SOURCE="<zlib_root_dir>" -s NO_ZLIB=0 -j8 --toolset=msvc-14.2 --stagedir=stage64 address-model=64 link=shared --prefix="<target_installation_dir>" --with-thread --with-date_time --with-program_options --with-iostreams --with-filesystem --with-system --with-serialization install`
|
||||
|
||||
The `--with-xxx` arguments list the modules we need for cgal.
|
||||
The `--with-xxx` arguments list the modules we need for CGAL.
|
||||
`-j8` is the argument for multi threading build, 8 stands for 8 cores.
|
||||
`--toolset=msvc-14.2` the version of msvc used for the build
|
||||
`--stagedir=stage64` and `address-model=64` to use 64 bits
|
||||
|
|
@ -22,4 +22,4 @@ The `--with-xxx` arguments list the modules we need for cgal.
|
|||
`-s NO_BZIP2=0` and `-s NO_ZLIB=0 ` to not ignore the zlib and bzip2 compilations
|
||||
` -s BZIP2_SOURCE="<bzip2_root_dir>"` and `-s ZLIB_SOURCE="<zlib_root_dir>"` the paths to the source directories downloaded in the previous step.
|
||||
|
||||
This will build zlib and bzip2 from source, and use the result to build boost_io_stream.
|
||||
This will build `zlib` and `bzip2` from source, and use the result to build boost_io_stream.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ I write:
|
|||
|
||||
``` c++
|
||||
if(!(n==0 || dleft_frac >= float_prior(float_prior(1.)))) {
|
||||
// do somehing,
|
||||
// do something,
|
||||
// print A LOT of information on std::cerr,
|
||||
// dump the input triangulation into a file,
|
||||
// ...
|
||||
|
|
@ -26,7 +26,7 @@ I write:
|
|||
|
||||
```
|
||||
|
||||
But that modification can only be temporay, and I cannot commit it into CGAL because the `if(..)` would be evaluated even with CGAL_NDEBUG defined. And thus I have to rewrite it again if the same assertion triggers again on a different data set!
|
||||
But that modification can only be temporary, and I cannot commit it into CGAL because the `if(..)` would be evaluated even with CGAL_NDEBUG defined. And thus I have to rewrite it again if the same assertion triggers again on a different data set!
|
||||
|
||||
Note that the expansion of `CGAL_assertion(expr);` is similar to:
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ that expands to:
|
|||
}
|
||||
```
|
||||
|
||||
The fourth parameter of CGAL::assertion_fail is a plain string, with the default value "". That string is by default displayed in the `what()` message of the thrown exception.
|
||||
The fourth parameter of `CGAL::assertion_fail` is a plain string, with the default value "". That string is by default displayed in the `what()` message of the thrown exception.
|
||||
|
||||
The trick is:
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ The trick is that we can call almost any function/functor, in a sequence using t
|
|||
CGAL_assertion( n==0, (dump_triangulation(tr), dump_point(point_a), ""))
|
||||
```
|
||||
|
||||
to call also `dump_point(point_a)`. And actually the most convient way is to use lambda expressions, for example in this code:
|
||||
to call also `dump_point(point_a)`. And actually the most convenient way is to use lambda expressions, for example in this code:
|
||||
|
||||
```c++
|
||||
if(it == (points_.end() - 2)) {
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Makefiles with CMake; however other generators are supported by CMake,
|
|||
too. In general, it is also advised to be familiar with the
|
||||
[distribution build procedure](https://doc.cgal.org/latest/Manual/installation.html),
|
||||
as the branch-build only selects another path to the main
|
||||
`CMakeLists.txt` file (i.e., picks it "from a branch" instead of "from a
|
||||
`CMakeLists.txt` file (i.e. picks it "from a branch" instead of "from a
|
||||
distribution").
|
||||
|
||||
## Example
|
||||
|
|
@ -224,6 +224,6 @@ library-objects and header files from the branch to a predefined
|
|||
directory, `CMAKE_INSTALLATION_PREFIX`. Then, if you want to use the
|
||||
installed version, you need to set
|
||||
`$CGAL_DIR=$CMAKE_INSTALLATION_PREFIX` accordingly, thereby detaching
|
||||
the installed files from the branch and loosing the connection to the
|
||||
the installed files from the branch and losing the connection to the
|
||||
source-code management system. For most purposes there is no need to
|
||||
install CGAL.
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ Remarks:
|
|||
- External users using headers with concurrency-enabled code also have
|
||||
to ensure to give the right parameters to the compiler.
|
||||
- In case we go for CTest, tests there can have properties: PROCESSORS
|
||||
and RUN\_SERIAL, which should be set when testing parallized code.
|
||||
and RUN\_SERIAL, which should be set when testing parallelized code.
|
||||
|
||||
## Which mechanism to enable or disable parallelism
|
||||
|
||||
|
|
@ -246,7 +246,7 @@ Parallel\_tag, he must provide one specialization by tag.
|
|||
|
||||
**Using is\_convertible**
|
||||
|
||||
Note that it makes it possible to have some inheritage amongst tags.
|
||||
Note that it makes it possible to have some inheritance amongst tags.
|
||||
|
||||
``` {.cpp}
|
||||
// Default: sequential
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ A python script is given to do so:
|
|||
This will generate all the files you need in `${TOOLCHAIN_PATH}`.
|
||||
|
||||
## Building GMP
|
||||
We will now build a version of GMP for Android, using the precedently generated toolchain.
|
||||
We will now build a version of GMP for Android, using the previously generated toolchain.
|
||||
In the GMP sources dir, do the following:
|
||||
```bash
|
||||
> export CC=${TOOLCHAIN_PATH}/bin/clang
|
||||
|
|
@ -110,7 +110,7 @@ Notes:
|
|||
|
||||
## Build an Example
|
||||
|
||||
Since Android 5.0 (API level 21), an executable needs to be PIE (Position independant executable) to work. To make your executable PIE, you need to add `-fPIE` to the CXX flags, and `-fPIE -pie` to the linker flags
|
||||
Since Android 5.0 (API level 21), an executable needs to be PIE (Position independent executable) to work. To make your executable PIE, you need to add `-fPIE` to the CXX flags, and `-fPIE -pie` to the linker flags
|
||||
|
||||
```bash
|
||||
> cmake -DCMAKE_CXX_FLAGS="-std=c++11 -fPIE" -DCMAKE_EXE_LINKER_FLAGS="-fPIE -pie" .
|
||||
|
|
|
|||
|
|
@ -262,7 +262,7 @@ where `<demodir>` is a name that corresponds (at least in part) to the
|
|||
package for which it is a demo.
|
||||
|
||||
The file `README` should contain information about what the program
|
||||
does, and how to compile it (i.e., what graphical libraries are needed,
|
||||
does, and how to compile it (i.e. what graphical libraries are needed,
|
||||
etc...). Note that, in contrast to example and test programs, demo
|
||||
programs more often need to submit a `CMakeLists.txt` since different
|
||||
demos will require different libraries and thus the `CMakeLists.txt` for
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
* [doxygen](#doxygen)
|
||||
* [Syntax Highlighting](#syntax-highlighting)
|
||||
* [MathJax](#mathjax)
|
||||
* [Building The Documentation](#building-the-documentation)
|
||||
* [Building the Documentation](#building-the-documentation)
|
||||
* [Building Only a Single Package](#building-only-a-single-package)
|
||||
* [Looking at the Result](#looking-at-the-result)
|
||||
* [Html output postprocessing: `html_output_post_processing.py`](#html-output-postprocessing-html_output_post_processingpy)
|
||||
|
|
@ -14,7 +14,7 @@
|
|||
* [Releasing the Documentation](#releasing-the-documentation)
|
||||
* [Changing things](#changing-things)
|
||||
* [PDF Output](#pdf-output)
|
||||
* [Using Doxygen](#using-doxygen)
|
||||
* [Using doxygen](#using-doxygen)
|
||||
* [Alternative (linux,windows)](#alternative-linuxwindows)
|
||||
|
||||
<!--TOC-->
|
||||
|
|
@ -114,7 +114,7 @@ branch is too old. Try: `make Documentation_doc`.
|
|||
To build the documentation with Visual Studio, build the `doc` target in
|
||||
Visual Studio.
|
||||
|
||||
With a self-built Doxygen, or with Doxygen from MacPorts
|
||||
With a self-built doxygen, or with doxygen from MacPorts
|
||||
(`/opt/local/bin/doxygen`) you will probably need to adjust the CMake
|
||||
variable `DOXYGEN_EXECUTABLE` to point to the right location.
|
||||
|
||||
|
|
@ -183,7 +183,7 @@ to install python dependencies on machine you do not administrate.
|
|||
Using PIP
|
||||
- Install python
|
||||
- pip install libxml
|
||||
- install bibtex via eg miktex
|
||||
- install bibtex via e.g. MiKTeX from https://miktex.org/
|
||||
- install perl from http://strawberryperl.com/
|
||||
|
||||
|
||||
|
|
@ -251,7 +251,7 @@ if things are changed.
|
|||
Please note that the pdf output is not yet bug-free and largely a work
|
||||
in progress.
|
||||
|
||||
#### Using Doxygen
|
||||
#### Using doxygen
|
||||
|
||||
In case you want the PDF output of your package:
|
||||
|
||||
|
|
@ -268,14 +268,14 @@ in progress.
|
|||
|
||||
Another option is to use the html to create a pdf.
|
||||
|
||||
Open in a new firefox window the user manual and the classified ref man.
|
||||
Open in a new Firefox window the user manual and the classified ref man.
|
||||
Open in different tabs, all the pages you want to print.
|
||||
|
||||
You can then use the [firefox extension "Print pages to PDF"](https://addons.mozilla.org/fr/firefox/addon/print-pages-to-pdf/)
|
||||
to print all the tabs into one pdf. In the preferences of that firefox
|
||||
You can then use the [Firefox extension "Print pages to PDF"](https://addons.mozilla.org/fr/firefox/addon/print-pages-to-pdf/)
|
||||
to print all the tabs into one pdf. In the preferences of that Firefox
|
||||
extension, make sure that the checkbox `PrintMedia` of the [tab `Pdf (webpage)->Styling`](http://printpdf.pf-control.de/index.php/en/styling/articles/styleing-preferences.html)
|
||||
is checked. That option instructs the extension to print using the CSS
|
||||
style dedicated to "print" media (in Doxygen, that tweaks several
|
||||
style dedicated to "print" media (in doxygen, that tweaks several
|
||||
things, and particularly the navigation box is hidden).
|
||||
|
||||
An example of the result can be found
|
||||
|
|
@ -285,8 +285,8 @@ An example of the result can be found
|
|||
- There are issues with missing MathJax formulas on some machines
|
||||
and we have not figured the reason for this yet.
|
||||
- Solution 1: disable MathJax globally or in your package. Just
|
||||
modifying `PackageName/doc/PackageName/Doxyfile.in`, i.e.,
|
||||
adding line
|
||||
modifying `PackageName/doc/PackageName/Doxyfile.in`, i.e.
|
||||
adding the line
|
||||
```
|
||||
Don't commit this change
|
||||
USE_MATHJAX = NO
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
[Writing Documentation](Writing-Documentation) : How to write Documentation for `CGAL` and a list of Doxygen resources
|
||||
[Writing Documentation](Writing-Documentation) : How to write Documentation for `CGAL` and a list of doxygen resources
|
||||
|
||||
[Building the Documentation](Building-the-Documentation) : How to build the Documentation and the involved tools
|
||||
|
||||
[Doxygen FAQ](Doxygen-FAQ) : Common issues and guidelines for using Doxygen
|
||||
[Doxygen FAQ](Doxygen-FAQ) : Common issues and guidelines for using doxygen
|
||||
|
|
|
|||
|
|
@ -112,5 +112,5 @@ INPUT += ${CGAL_PACKAGE_INCLUDE_DIR}/CGAL/boost/graph/Euler_operations.h \
|
|||
|
||||
As described in the
|
||||
[Coding](Developing-Features-with-Git#coding)
|
||||
section, use the Doxygen macro `\deprecated` to deprecate a class. The
|
||||
section, use the doxygen macro `\deprecated` to deprecate a class. The
|
||||
deprecation should be done consistently in the source code file.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
<!--TOC-->
|
||||
|
||||
# Table of Contents
|
||||
* [Writing Doxygen documentation in CGAL](#writing-doxygen-documentation-in-cgal)
|
||||
* [Writing doxygen documentation in CGAL](#writing-doxygen-documentation-in-cgal)
|
||||
* [Directory Layout](#directory-layout)
|
||||
* [PackageDescription.txt](#packagedescriptiontxt)
|
||||
* [User Manuals](#user-manuals)
|
||||
|
|
@ -23,7 +23,7 @@
|
|||
* [Classified Reference Manual (used in PackageDescription.txt)](#classified-reference-manual-used-in-packagedescriptiontxt)
|
||||
* [Named Parameters](#named-parameters-macros)
|
||||
* [Miscellaneous Macros](#miscellaneous-macros)
|
||||
* [New Packages and Doxygen Configuration](#new-packages-and-doxygen-configuration)
|
||||
* [New Packages and doxygen Configuration](#new-packages-and-doxygen-configuration)
|
||||
* [Package Overview](#package-overview)
|
||||
* [Doxyfile.in](#doxyfilein)
|
||||
* [Doxyfile.in defaults](#doxyfilein-defaults)
|
||||
|
|
@ -35,7 +35,7 @@
|
|||
|
||||
<!--TOC-->
|
||||
|
||||
## Writing Doxygen documentation in CGAL
|
||||
## Writing doxygen documentation in CGAL
|
||||
|
||||
Doxygen is a documentation tool that allows to put documentation in C++
|
||||
comments in the source code. This can either be the real or fake header
|
||||
|
|
@ -70,7 +70,7 @@ Triangulation_2/doc/Triangulation_2/
|
|||
PackageDescription.txt // the package overview
|
||||
Triangulation_2.txt // the user manual
|
||||
examples.txt
|
||||
Doxyfile.in // the Doxygen configuration
|
||||
Doxyfile.in // the doxygen configuration
|
||||
dependencies // a file listing the dependencies
|
||||
```
|
||||
|
||||
|
|
@ -178,7 +178,7 @@ hierarchy in one place.
|
|||
|
||||
The set-up allows a fully free form doxygen documentation. To keep with
|
||||
the general style in CGAL some rules should be followed. The User Manual
|
||||
should be the Doxygen mainpage of the package.
|
||||
should be the doxygen mainpage of the package.
|
||||
|
||||
A typical example is (file: `Triangulation_2.txt`):
|
||||
|
||||
|
|
@ -740,7 +740,7 @@ with their namespace for `\cgalHasModel`.
|
|||
If you have some functions that are public but you do not want them to
|
||||
appear in the reference manual, the way [recommended by
|
||||
doxygen](http://www.stack.nl/~dimitri/doxygen/manual/commands.html#cmdcond)
|
||||
to ignore parts of a file is to surround the a bloc with `/// \cond SKIP_IN_MANUAL` and `/// \endcond`.
|
||||
to ignore parts of a file is to surround the a block with `/// \cond SKIP_IN_MANUAL` and `/// \endcond`.
|
||||
|
||||
If you want to expose a different portion of the code to doxygen (to
|
||||
hide an implementation detail for example), for convenience the macro
|
||||
|
|
@ -891,7 +891,7 @@ For example:
|
|||
- `\cgalModifEnd` : End of a paragraph modified.
|
||||
- `\cgalReleaseNumber` : The release version (available only in the `Documentation` package)
|
||||
|
||||
### New Packages and Doxygen Configuration
|
||||
### New Packages and doxygen Configuration
|
||||
|
||||
#### Package Overview
|
||||
|
||||
|
|
@ -922,7 +922,7 @@ In `Documentation/doc/Documentation/packages.txt`:
|
|||
|
||||
#### Doxyfile.in
|
||||
|
||||
The Doxygen configurations of each package are maintained in the file
|
||||
The doxygen configurations of each package are maintained in the file
|
||||
`My_package/doc/My_package/Doxyfile.in`. This provides a common
|
||||
configuration base for all packages and enables to tweak the output to
|
||||
the package requirements.
|
||||
|
|
@ -1063,7 +1063,7 @@ versions highlighted ("diff") can be done using latexdiff. However,
|
|||
latexdiff finds "false positive" differences in the links (because link
|
||||
"target" names contain a different unique ID each time); this can be
|
||||
solved setting PDF\_HYPERLINKS to NO in the Doxyfile, at the expense of
|
||||
loosing the links.
|
||||
losing the links.
|
||||
|
||||
For some problems with the current output, please see here
|
||||
**[Standalone Problems](Standalone-Problems)**
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ but that is discouraged because variables like `CMAKE_CXX11_COMPILE_FEATURES` ar
|
|||
[CMake compile features]: https://cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
|
||||
[list of know features]: https://cmake.org/cmake/help/v3.6/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html#prop_gbl:CMAKE_CXX_KNOWN_FEATURES
|
||||
|
||||
This requires CMake 3.1 or later, but there is a compatibility mode: the example will not be configured, with a warning, iif an older version of CMake is used.
|
||||
This requires CMake 3.1 or later, but there is a compatibility mode: the example will not be configured, with a warning, if an older version of CMake is used.
|
||||
|
||||
### For a whole directory (of examples or of a demo)
|
||||
To modify the CMakeLists.txt of a demo, to make it use C++11 or C++14, that is even easier: add that line before the definition of any target:
|
||||
|
|
|
|||
|
|
@ -15,6 +15,6 @@ services:
|
|||
- <https://cgal.geometryfactory.com/CGAL/testsuite/>: the
|
||||
testsuite results collection pages,
|
||||
- <https://cgal.geometryfactory.com/CGAL/Manual_doxygen_test/>:
|
||||
the manual testsuite, using Doxygen,
|
||||
the manual testsuite, using doxygen,
|
||||
- <https://cgal.geometryfactory.com/CGAL/Members/wiki/>: the internal developer
|
||||
wiki.
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ build_cgal_library(CGAL_Parallel CGALParallel "")
|
|||
|
||||
The macro `build_cgal_library` declares a new library to CMake, using
|
||||
`add_library`. It does extra work for name-mangling support on Windows,
|
||||
and sets the VERSION and SOVERSION properties of the library. Here are
|
||||
and sets the `VERSION` and `SOVERSION` properties of the library. Here are
|
||||
the arguments of the macro:
|
||||
|
||||
- The first argument is the name of the library.
|
||||
|
|
|
|||
|
|
@ -78,6 +78,6 @@ Then define a macro for all packages you think you are using:
|
|||
```
|
||||
#define CGAL_AABB_TREE_COMMERCIAL_LICENSE 20140101
|
||||
```
|
||||
The name of the macro is `CGAL_`+short name of the package uppercased+`_COMMERCIAL_LICENSE`.
|
||||
The name of the macro is `CGAL_`+short name of the package in uppercase+`_COMMERCIAL_LICENSE`.
|
||||
The number following corresponds to the release date for which you have a
|
||||
commercial license.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@
|
|||
* [Command line options for the initial set up](#command-line-options-for-the-initial-set-up)
|
||||
* [Sending results](#sending-results)
|
||||
* [List of miscellaneous configurable variables](#list-of-miscellaneous-configurable-variables)
|
||||
* [Testing with Visual Studio on cygwin](#testing-with-visual-studio-on-cygwin)
|
||||
* [Testing with Visual Studio on Cygwin](#testing-with-visual-studio-on-cygwin)
|
||||
* [`add_toc_to_github_wiki_page.py`](#add_toc_to_github_wiki_pagepy)
|
||||
* [Setup a testsuite with ctest](#setup-a-testsuite-with-ctest)
|
||||
* [The .autocgalrc file](#the-autocgalrc-file)
|
||||
|
|
@ -562,7 +562,7 @@ otherwise the value should be `' '`.
|
|||
`wget` and `ftp`. Set it to `y` to use `curl`.
|
||||
|
||||
`FTP_OPTS` specifies the options for `ftp`. On Linux systems it should
|
||||
be `-p -v -n` (the default), on cygwin it should be `-v -n`.
|
||||
be `-p -v -n` (the default), on Cygwin it should be `-v -n`.
|
||||
|
||||
`NICE_OPTIONS` specifies the command line options to pass to the `nice`
|
||||
command, which is used to prevent the test-suite from keeping all CPU
|
||||
|
|
@ -570,13 +570,13 @@ time for itself. The default value is `' '-19' '`.
|
|||
|
||||
`ULIMIT_OPTIONS` specifies the command line options to pass to the
|
||||
`ulimit` command, which is used to prevent the test-suite from using
|
||||
various system ressources. It can be used to help killing looping
|
||||
various system resources. It can be used to help killing looping
|
||||
programs. For example, specifying `-c 0 -t 10800 -v 2000000` will
|
||||
prevent the creation of dumped core files, will stop processes after 3
|
||||
hours, and will kill them if they reach 2GB of memory. The default value
|
||||
is empty (no limit).
|
||||
|
||||
### Testing with Visual Studio on cygwin
|
||||
### Testing with Visual Studio on Cygwin
|
||||
|
||||
In order to test with Visual Studio you need to use Cygwin and set up
|
||||
the environment for the command line compiler.
|
||||
|
|
@ -610,15 +610,15 @@ considered:
|
|||
|
||||
The variables `INCLUDE, LIB` and `LIBPATH` will be used by the Visual
|
||||
C++ compiler *directly*, that is, without the path translation that
|
||||
cygwin usually performs. Thus, the values for these variables must be a
|
||||
Cygwin usually performs. Thus, the values for these variables must be a
|
||||
verbatim copy of the values defined in the `vcvars32.bat` of your
|
||||
Visual Studio installation.
|
||||
|
||||
On the other hand, the `PATH` variable will be used by cygwin itself to
|
||||
On the other hand, the `PATH` variable will be used by Cygwin itself to
|
||||
locate the components of the command line tools (cl.exe, link.exe,
|
||||
etc.), thus, each Windows path specified in the PATH definition on
|
||||
`vcvars32.bat` must be converted to a POSIX path and properly appended
|
||||
to the cygwin PATH variable.
|
||||
to the Cygwin PATH variable.
|
||||
|
||||
Below is a sample 'setup' script for Visual C++ 9.0:
|
||||
```
|
||||
|
|
@ -771,7 +771,7 @@ In it, you can set the values for the interesting CMake variables with this synt
|
|||
```
|
||||
SET(variable value CACHE type "")
|
||||
```
|
||||
This file is used to populate the cache (`CMakeCache.txt`). Note that you should leave the content of `CMAKE_CXX_FLAGS_DEBUG` empty for a Release platform, or `CMAKE_CXX_FLAGS_Release` for a Debug platform, to prevent false information to end up in the testusite page.
|
||||
This file is used to populate the cache (`CMakeCache.txt`). Note that you should leave the content of `CMAKE_CXX_FLAGS_DEBUG` empty for a Release platform, or `CMAKE_CXX_FLAGS_Release` for a Debug platform, to prevent false information to end up in the testsuite page.
|
||||
|
||||
`file` is the absolute path to the cmake initialization file containing all cmake information. Note that it needs to be exported.
|
||||
example:
|
||||
|
|
@ -801,7 +801,7 @@ set(CGAL_DISABLE_GMP ON CACHE BOOL "")
|
|||
|
||||
set(WITH_LEDA ON CACHE BOOL "")
|
||||
set(LEDA_INCLUDE_DIR /deps/include CACHE STRING "")
|
||||
set(LEDA_LIBRARIES /deps/lib/libleda_numbers.so CACHE STING "")
|
||||
set(LEDA_LIBRARIES /deps/lib/libleda_numbers.so CACHE STRING "")
|
||||
```
|
||||
|
||||
On Windows, in the `REFERENCE_PLATFORMS_DIR`, you can also have a directory per platform, named `${PLATFORM}`, containing a setup file, defining the environment of the platform, including the export of the `PATH` variable, making all the needed dlls available. This setup file **must** define the variable `CONFIG_TYPE` and export it. This variable can be `Release` or `Debug`, and is used in the script `autotest_cgal_with_ctest` to correctly run ctest.
|
||||
|
|
@ -822,7 +822,7 @@ This is only used if the option `-g` is given to `autotest_cgal_with_ctest`.
|
|||
#### The ssh directory (remote testsuites)
|
||||
This directory is only used for remote testsuites. It should contain a copy of all the ssh keys you need to contact the host that will run the tests and the upload destination, the associated `known_hosts`, and a `config` file to configure which key should be used for which host.
|
||||
|
||||
**Tip**: to get the known host, you can modify the docker run call in `autotest_cgal_with_ctest` by adding -i and /bin/bash to access the configured docker container, connect by ssh to each of the mentionned hosts, and once all of them has been added to the known hosts, you can call
|
||||
**Tip**: to get the known host, you can modify the docker run call in `autotest_cgal_with_ctest` by adding -i and /bin/bash to access the configured docker container, connect by ssh to each of the mentioned hosts, and once all of them has been added to the known hosts, you can call
|
||||
```
|
||||
cp ~/.ssh/known_hosts /tmp_ssh
|
||||
```
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ Then Jenny can ask her branch to be merged into master by opening a
|
|||
[Pull Request](Source-Code-Management-with-Git#pull-request). Once the pull-request passes the continuous integration tests (see [below](#continuous-integration)), the release management team will eventually select the pull-request to be tested in the testsuite, by merging it in the [`integration` branch](#integration-branch) from the `cgal-dev` repository.
|
||||
|
||||
### Continuous Integration
|
||||
Github uses a continuous integration process to swiftly notice errors in a pull request
|
||||
GitHub uses a continuous integration process to swiftly notice errors in a pull request
|
||||
without having to wait for the nightly batch. This process requires a few related files to
|
||||
be set up correctly, especially when introducing a new package. Read more on the following
|
||||
wiki page: [Travis CI Explained and Check List for a New Package](Travis-CI-Explained-and-Check-List-for-a-New-Package-[deprecated])
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ A third parameter can be used to name the branch you want to checkout.
|
|||
|
||||
**Note for Windows users:** `git-new-workdir` needs symbolic links. Do
|
||||
not try to use it on Windows unless you only use git.exe from Cygwin.
|
||||
Git.exe from msysgit or Tortoize will not work with such a working
|
||||
Git.exe from msysgit or Tortoise will not work with such a working
|
||||
directory.
|
||||
|
||||
We also discuss (for advanced users) [how to combine several orthogonal features in one branch](Developing-Features-with-Git#developing-and-committing-to-several-orthogonal-feature-branches).
|
||||
|
|
@ -234,5 +234,5 @@ apply it to all of them.
|
|||
When installing git for Windows from github.io:
|
||||
* Tick OpenSSH library
|
||||
* Set `GIT_SSH = TortoisePlink.exe`
|
||||
* No need for alias for ssh or scp, instead with cygwin setup install: ssh and ssh-pageant
|
||||
* No need for alias for ssh or scp, instead with Cygwin setup install: ssh and ssh-pageant
|
||||
* No need for a directory .ssh as the keys are stored in pageant
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ about Git and Tortoise Git [there (nice course notes, in
|
|||
french)](http://marc.chevaldonne.free.fr/ens_rech/Csharp_XML_GI_2010_2011_files/Quick%20Guide%20Git%20TortoiseGit.pdf).
|
||||
|
||||
In the following commands of the command-line client of Git (`git` on
|
||||
Linux/Mac OS, `git.exe` on Windows cygwin) are given. They naturally
|
||||
Linux/Mac OS, `git.exe` on Windows Cygwin) are given. They naturally
|
||||
translate to GUI-guided actions. Intuitive GUIs exists. For instance,
|
||||
for **Windows** (TortoiseGit, which is similar to TortoiseSVN, or
|
||||
[Git Extensions](http://gitextensions.github.io/), that integrate
|
||||
|
|
@ -99,7 +99,7 @@ At this point we also *strongly recommend* to run
|
|||
which installs a pre-commit hook to Jenny's local repository (Windows
|
||||
users: there is a git-bash in the context menu of Git in which you can
|
||||
run the script). The hook gives you *early alerts* for commit that will
|
||||
be rejected by the central repo when you try to push your changes to it.
|
||||
be rejected by the central repository when you try to push your changes to it.
|
||||
|
||||
With:
|
||||
|
||||
|
|
@ -368,7 +368,7 @@ remote.
|
|||
# if empty, everything is pushed
|
||||
```
|
||||
|
||||
Similarily,
|
||||
Similarly,
|
||||
|
||||
``` {.bash}
|
||||
> git log --branches --not --remotes
|
||||
|
|
|
|||
|
|
@ -340,7 +340,7 @@ non-conforming commit messages.
|
|||
|
||||
### Branch-build
|
||||
|
||||
CGAL can be built from a branch directly, i.e., there is no need to
|
||||
CGAL can be built from a branch directly, i.i. there is no need to
|
||||
create an internal release. The developer Jenny can build the CGAL
|
||||
libraries from the branch she is currently working on. The [branch build
|
||||
has its own wiki page](Branch-Build).
|
||||
|
|
@ -350,7 +350,7 @@ has its own wiki page](Branch-Build).
|
|||
- Do not put automatically generated files into the repository.
|
||||
- The following files are always excluded from releases: `TODO`,
|
||||
`todo`, `TODO.txt`, `todo.txt`, `TO_DO`, `Doxyfile` and `*.dxy` (as
|
||||
as long Doxygen is not officially supported). more generally, you
|
||||
as long doxygen is not officially supported), more generally, you
|
||||
can have a look at the file
|
||||
`Maintenance/release_building/global_dont_submit` for the full list
|
||||
of files or file patterns that are ignored globally during the
|
||||
|
|
@ -428,7 +428,7 @@ Remarks:
|
|||
identified by a hash (replacing revision numbers).
|
||||
- **push** and **fetch** simply update the remote (push) or the local
|
||||
graph (fetch) accordingly. Be aware that **pull**, the direct
|
||||
counterpart to **push**, also updates the workspace (i.e., apply
|
||||
counterpart to **push**, also updates the workspace (i.i. apply
|
||||
changes to the checkout files).
|
||||
|
||||
## Further Directions
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@
|
|||
## Introduction
|
||||
|
||||
The CGAL test suite is a way to test the compilation and execution of
|
||||
CGAL programs automatically (i.e., without user interaction) on a number
|
||||
CGAL programs automatically (i.e. without user interaction) on a number
|
||||
of different platforms. A platform in this context refers to a
|
||||
combination of an operating system, a compiler, and a set of flags
|
||||
provided in the compilation command-line. Examples of the latter are
|
||||
|
|
@ -70,7 +70,7 @@ The **test suite** helps the developer(s) of a package to
|
|||
section](#Using_the_code_coverage_tool_gcov) for a
|
||||
description of a tool you can use to test code coverage).
|
||||
- Use more than one instantiation of templated functions or classes.
|
||||
- A lot of classes in CGAL can be parametrized by traits classes, so
|
||||
- A lot of classes in CGAL can be parameterized by traits classes, so
|
||||
that they are usable with different kernels. In such cases more than
|
||||
one kernel should be used for testing.
|
||||
- Recall that the CGAL checks, such as `CGAL_precondition` and
|
||||
|
|
@ -136,7 +136,7 @@ contains input files for the test programs.
|
|||
|
||||
### `*.cin` files
|
||||
|
||||
If a test program program.cpp requires input from standard input (i.e.,
|
||||
If a test program program.cpp requires input from standard input (i.e.
|
||||
cin), you should put a file called program.cin in the test directory.
|
||||
The test suite will then execute the program using the command
|
||||
`./program < program.cin`
|
||||
|
|
@ -144,7 +144,7 @@ The test suite will then execute the program using the command
|
|||
### `*.cmd` files
|
||||
|
||||
If a test program program.cpp requires input from the command line
|
||||
(i.e., `-f` `*.off` ), you should put a file called program.cmd in the test
|
||||
(i.e. `-f` `*.off` ), you should put a file called program.cmd in the test
|
||||
directory. For each line in `program.cmd`, the testsuite will then
|
||||
execute the program with the full line as arguments.
|
||||
|
||||
|
|
@ -423,7 +423,7 @@ We can see that:
|
|||
|
||||
## Checking Headers
|
||||
|
||||
travis compiles each header separarately that is referenced in the manual.
|
||||
travis compiles each header separately that is referenced in the manual.
|
||||
This checks that each header makes all necessary `#include`.
|
||||
|
||||
In order to perform the check locally you need g++ or clang, and you have
|
||||
|
|
@ -513,7 +513,7 @@ The testsuite will generate the following output files:
|
|||
every program that was tested on platform <platform> in the test
|
||||
directory <testdir>. The first line tells if the compilation was
|
||||
successful and the second line tells if the execution was successful
|
||||
(i.e., the program returned the value 0) (see Section [`test`](Directory-Structure-for-Packages#test-subdirectory)
|
||||
(i.e. the program returned the value 0) (see Section [`test`](Directory-Structure-for-Packages#test-subdirectory)
|
||||
for more details).
|
||||
- `<testdir>/ProgramOutput.<program>.<platform>` This file contains the
|
||||
console output from the test program `<program.cpp>` run on platform
|
||||
|
|
|
|||
|
|
@ -158,7 +158,7 @@ and finally
|
|||
- Install Ruby
|
||||
- Linux: check your package manager
|
||||
- Windows
|
||||
- Note: you should run everything in cmd.exe and not a cygwin
|
||||
- Note: you should run everything in cmd.exe and not a Cygwin
|
||||
shell.
|
||||
- go to <http://rubyinstaller.org/downloads/> and download
|
||||
RubyInstaller 2.0.0 and the appropriate Development Kit
|
||||
|
|
|
|||
2
Home.md
2
Home.md
|
|
@ -1,5 +1,5 @@
|
|||
Welcome to the cgal-dev wiki!
|
||||
|
||||
You will find here the [Guidelines](Guidelines) for CGAL developers as well as
|
||||
[informations for new developers](Information-for-New-Developers) that will help
|
||||
[information for new developers](Information-for-New-Developers) that will help
|
||||
new developers to quickly get started with development in CGAL.
|
||||
|
|
|
|||
|
|
@ -32,13 +32,13 @@ Once your mentor has introduced you on the [CGAL Editorial Board mailing list](M
|
|||
- Configure notifications at
|
||||
<https://github.com/settings/notifications>.
|
||||
|
||||
Once this is done, send an email with your Github ID to [@sloriot](https://github.com/sloriot), who will
|
||||
Once this is done, send an email with your GitHub ID to [@sloriot](https://github.com/sloriot), who will
|
||||
add you to the list of members of the CGAL organization so that you can
|
||||
see the private repositories.
|
||||
|
||||
### Publicizing your membership
|
||||
|
||||
Once your Github account has been created, and added by an admin to the CGAL organization, you have to publicize your membership, so that all our Github actions work correctly. Follow [these steps](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-membership-in-organizations/publicizing-or-hiding-organization-membership) to do so.
|
||||
Once your GitHub account has been created, and added by an admin to the CGAL organization, you have to publicize your membership, so that all our GitHub actions work correctly. Follow [these steps](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-membership-in-organizations/publicizing-or-hiding-organization-membership) to do so.
|
||||
|
||||
## Setting up your development environment
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
# Table of Contents
|
||||
* [Requirements](#requirements)
|
||||
* [Getting the Compilator tools](#getting-the-compilator-tools)
|
||||
* [Getting the Compilation tools](#getting-the-compilation-tools)
|
||||
* [Building GMP](#building-gmp)
|
||||
* [Building MPFR](#building-mpfr)
|
||||
* [Building Boost (Optional)](#building-boost-optional)
|
||||
|
|
@ -32,12 +32,12 @@
|
|||
[MPFR sources]: http://www.mpfr.org/mpfr-current/#download
|
||||
[CGAL sources]: https://www.cgal.org/download/last
|
||||
|
||||
## Getting the Compilator tools
|
||||
## Getting the Compilation tools
|
||||
The first step for cross-compiling a library to arm is to get the right tools for it:
|
||||
```bash
|
||||
> sudo apt-get install gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf
|
||||
```
|
||||
Those are the c and c++ compilators that will take care of the cross-compilation to a 32bit arm platform.
|
||||
Those are the C and C++ compilers that will take care of the cross-compilation to a 32bit arm platform.
|
||||
|
||||
For 64bit:
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ For 64bit:
|
|||
In the rest of this walkthrough, we will use the 32bit tools. For 64bit do the exact same thing but replacing `arm-linux-gnueabihf` with `aarch64-linux-gnu`.
|
||||
|
||||
## Building GMP
|
||||
In the GMP sources dir, do the following:
|
||||
In the GMP sources directory, do the following:
|
||||
```bash
|
||||
> CC=/usr/bin/arm-linux-gnueabihf-gcc ./configure --prefix=${GMP_PATH} --enable-shared --host=${TARGET_TRIPLET}
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ In the GMP sources dir, do the following:
|
|||
|
||||
## Building MPFR
|
||||
This is very similar to building GMP.
|
||||
In the MPFR sources dir, do the following:
|
||||
In the MPFR sources directory, do the following:
|
||||
|
||||
```bash
|
||||
> CC=/usr/bin/arm-linux-gnueabihf-gcc ./configure --prefix=${MPFR_PATH} --enable-shared --host=${TARGET_TRIPLET} --with-gmp=${GMP_PATH}
|
||||
|
|
@ -112,7 +112,7 @@ Once we have this, we call cmake:
|
|||
CGAL is now ready to be used with an arm application.
|
||||
|
||||
Notes:
|
||||
- If you ommit `-DCGAL_test_cpp_version_RUN_RES__TRYRUN_OUTPUT=201103L`, you will have to run cmake twice..
|
||||
- If you omit `-DCGAL_test_cpp_version_RUN_RES__TRYRUN_OUTPUT=201103L`, you will have to run cmake twice..
|
||||
- The options `-DCMAKE_CXX_FLAGS=-std=c++11 -DCGAL_test_cpp_version_RUN_RES=0 -DCGAL_test_cpp_version_RUN_RES__TRYRUN_OUTPUT=201103L` allow to use the C++11 standard. When CGAL is compiled with a C++11 compiler, the library Boost.Thread is no longer required, and Boost libraries can be used header-only. There is one exception: `CGAL_Core` still requires Boost.Thread. That is why we use the cmake option `-DWITH_CGAL_Core=FALSE`, to disable `CGAL_Core`. If you need `CGAL_Core`, then you will have to cross-compile Boost, and then set the appropriate CMake variables. Some packages have more dependencies. If you wish to use them, you will have to cross-compile them too.
|
||||
|
||||
## Setting up a testsuite
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ admins: sebastien.loriot@cgal.org and monique.teillaud@cgal.org
|
|||
|
||||
- [cgal-dev-commits](https://sympa.inria.fr/sympa/info/cgal-dev-commits):
|
||||
commits/pushes to the [cgal-dev](https://github.com/CGAL/cgal-dev)
|
||||
private repo AND the
|
||||
private repository AND the
|
||||
[cgal-public-dev](https://github.com/CGAL/cgal-public-dev) public
|
||||
repository.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
* [The script `hub`](#the-script-hub)
|
||||
* [Diff between two releases](#diff-between-two-releases)
|
||||
* [Merges in `integration`](#merges-in-integration)
|
||||
* [Use Github labels with `list_pull_requests.py`](#use-github-labels-with-list_pull_requestspy)
|
||||
* [Use GitHub labels with `list_pull_requests.py`](#use-github-labels-with-list_pull_requestspy)
|
||||
* [Use the script `git-show-content`](#use-the-script-git-show-content)
|
||||
|
||||
<!--TOC-->
|
||||
|
|
@ -54,7 +54,7 @@ hub merge https://github.com/CGAL/cgal/pull/3368
|
|||
# ...
|
||||
```
|
||||
|
||||
### Use Github labels with `list_pull_requests.py`
|
||||
### Use GitHub labels with `list_pull_requests.py`
|
||||
|
||||
The script `./Scripts/developer_scripts/list_pull_requests.py` is a Python script (compatible with Python 2.7 and Python 3.x).
|
||||
|
||||
|
|
@ -68,7 +68,7 @@ https://github.com/CGAL/cgal/pull/3437
|
|||
https://github.com/CGAL/cgal/pull/3323
|
||||
https://github.com/CGAL/cgal/pull/3293
|
||||
```
|
||||
to list all pull-requests that have a given github label, passed as the argument. The optional argument `--unmerged` only lists the pull-request with the label *that are not already merged in the current branch*.
|
||||
to list all pull-requests that have a given GitHub label, passed as the argument. The optional argument `--unmerged` only lists the pull-request with the label *that are not already merged in the current branch*.
|
||||
|
||||
Usage:
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Wednesday 5 September 2018, during the evening, there was a sort of brainstormin
|
|||
[`CloudCompare`]: https://www.danielgm.net/cc/
|
||||
|
||||
So, there was that brain storming about the naming of the application, and here are the proposals:
|
||||
- Cicada (in French a cicada is named Cigale, that is prononced like C-gal)
|
||||
- Cicada (in French a cicada is named Cigale, that is pronounced like C-gal)
|
||||
- Sakado (as a bad joke)
|
||||
- Cgala / Cigala
|
||||
- Cgalery / CGALery
|
||||
|
|
@ -21,15 +21,15 @@ See also [Other proposals after the first brainstorm (below)](#other-proposals-a
|
|||
|
||||
# Discussion
|
||||
## Cicada
|
||||
* :ok: The prononciation is all right in English, and various European languages.
|
||||
* :ok: The pronunciation is all right in English, and various European languages.
|
||||
* :ok: No trademark issue.
|
||||
* :heavy_minus_sign: cicada.org is squatted.
|
||||
|
||||
## Sakado
|
||||
* :x: Let's forget that one! It was a pun after cicada, because their prononciations are similar but with different vowels.
|
||||
* :x: Let's forget that one! It was a pun after cicada, because their pronunciations are similar but with different vowels.
|
||||
|
||||
## Cgala
|
||||
* :ok: Again a pun, around the pronciation of CGAL as C-gal, but that pun is acceptable.
|
||||
* :ok: Again a pun, around the pronunciation of CGAL as C-gal, but that pun is acceptable.
|
||||
* :heavy_minus_sign: There is company named [CGALA] in France.
|
||||
|
||||
[CGALA]: https://www.cgala.fr/
|
||||
|
|
@ -39,7 +39,7 @@ See also [Other proposals after the first brainstorm (below)](#other-proposals-a
|
|||
* :heavy_minus_sign: The name is used for various things. See [on Google](https://www.google.fr/search?q=cgalery).
|
||||
|
||||
## CGAL Studio
|
||||
* :ok: The name says what it is. It sounds professinal, maybe too professinal for the current state of the application.
|
||||
* :ok: The name says what it is. It sounds professional, maybe too professional for the current state of the application.
|
||||
|
||||
## Geomethree / geome3
|
||||
* A pun, acceptable.
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@ In cmake, since version 3.16, precompiled headers are created using the function
|
|||
|
||||
It is also possible, under certain circumstances, to use precompiled headers declared for other targets.
|
||||
To do so, the same function is used, but is given the option `REUSE_FROM` and another target, which is already using PCH, that will be shared with `target`.
|
||||
Note that this requires both targets to share the same set of compiler options, compiler flags and compiler definitions, which is undoubtly **a heavy restriction**.
|
||||
Note that this requires both targets to share the same set of compiler options, compiler flags and compiler definitions, which is undoubtedly **a heavy restriction**.
|
||||
Moreover, in usage with Qt moc system, a bug prevents the rcc, uic and moc commands to be ran on sources of a target that uses PCH the first time cmake is called. It means cmake must be called twice for it to work, but fortunately this bug has been fixed in version 3.18.
|
||||
For more informations, please visit the documentation of cmake ragarding this function :
|
||||
For more information, please visit the documentation of cmake regarding this function:
|
||||
https://cmake.org/cmake/help/v3.16/command/target_precompile_headers.html
|
||||
|
||||
# Examples
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Every Github Pull Request made in `CGAL/cgal` will trigger a Continous Integration tool named Travis CI, which will perform a series of tests in an Ubuntu environment. If successful, a green check will be added next to the last tested commit on the GitHub page of the PR, if failed a red cross. The orange dot indicates that the tests are ongoing. Clicking on the result mark will open a dialog containing a link redirecting to the tests page on Travis.
|
||||
Every GitHub Pull Request made in `CGAL/cgal` will trigger a Continuous Integration tool named Travis CI, which will perform a series of tests in an Ubuntu environment. If successful, a green check will be added next to the last tested commit on the GitHub page of the PR, if failed a red cross. The orange dot indicates that the tests are ongoing. Clicking on the result mark will open a dialog containing a link redirecting to the tests page on Travis.
|
||||
On this page, there is a list of jobs. The first one is named CHECK, the other ones test several packages, and each line reports if there are errors or not using the same mark system as used in GitHub. You can click on the job line to access its logs and look for any interesting information, most of the time the error(s) that caused the job to fail.
|
||||
|
||||
This article aims to explain the causes of failure of the CHECK job, and how to make it work.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
If you need to get feedback in a convenient way using the github infrastructure from other developers, you can open a pull-request in your own space (i.e., the _mine_ remote). The advantage compared to having it in the _cgal_ remote is that it will only notify people that subscribed to the notifications of your PR. Note that this will work only for public branches.
|
||||
If you need to get feedback in a convenient way using the GitHub infrastructure from other developers, you can open a pull-request in your own space (i.e. the _mine_ remote). The advantage compared to having it in the _cgal_ remote is that it will only notify people that subscribed to the notifications of your PR. Note that this will work only for public branches.
|
||||
|
||||
To do that go to you _mine_ space (`https://github.com/YOUR_GITHUB_ID/cgal/`) and select the branch you want to get a review of (you must have already pushed it to your _mine_ remote):
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue