HACKING

* Don't commit directly, instead make a pull request on GitHub.


Building from git
-----------------

To build from git, or without relying on the generated files in a source
release, automake, autoconf, libtool, pkg-config and git must be installed.

(Note, the exact packages needed for certain distros may be found in
.github/workflows/c-cpp.yml.)

Run

./bootstrap && ./configure --enable-relocatable

to set up and configure the source tree; optional configure arguments can be
supplied as normal.

See INSTALL (which is created by bootstrap) for instructions from this point
on.


Working in libenchant
---------------------

   When writing libenchant our priorities are

	1) Portable
	2) Maintainable & Documented
	3) Modular and well designed

    When you submit code for inclusion in libenchant, please keep those
things in mind.  Performance is not generally an issue: Enchant leaves the
heavy lifting to its spelling providers.  Specifically, this means:

	- Clarity of design and function are paramount
	- Make sure your code does not generate warnings
	- Please follow the formatting style


Formatting style
----------------

   The formatting style of libenchant is a mix of various styles.  Please
follow the style that seems to predominate in any given area of the code base; broadly, there are different styles for the Vala library code, providers and commands, and the tests.  The public header files are written in GLib style.

   Emacs users should use the supplied .dir-locals.el.

   Remember: Use tabs for indentation: that will keep your
code honest as you will be forced to split your routines into more
modular chunks (as detailed by Linus). 
   
   On top of that, please in Vala follow the conventions of typical Vala
code, and in C/C++:

	- Follow the Gtk+ cleanliness conventions for function
	  prototypes.

	- Follow the Gtk+ namespace convention for function names:
	  module_submodule_operation

	- Do not submit code that is just a temporary workaround for a
	  full fledged feature.  We do not want to maintain limited
	  features.  It is better to submit an implementation designed
	  to be expanded and enhanced, even if it is not completely
	  finished.

   All of this is to ensure the libenchant code will be kept within
reasonable margins of maintainability for the future: Remember, in two years
you will probably be far too busy to maintain your own contributions, and they
might become a burden to the program maintainers.

   libenchant is intended to be a foundation for a various document-centric
projects.

   Simplifying code in libenchant is important.  Simplifications are almost
always welcome.  But please don't reformat code you're not editing, even
where the formatting is inconsistent or ugly, as it makes the history of the
project harder to understand.


API documentation
-----------------

To generate API documentation, run

make doxygen

and open doxygen/html/index.html in a web browser.


Making a release
----------------

To make a release, you'll need woger:

https://github.com/rrthomas/woger

and gh:

https://cli.github.com

Having tested and pushed all the changes, update the version number in
configure.ac and write the NEWS entry and push those too.

Then execute:

make release