by moving the inclusion of buildlink3.mk files outside of the protected
region. This bug would be seen by users that have set PREFER_PKGSRC
or PREFER_NATIVE to non-default values.
BUILDLINK_PACKAGES should be ordered so that for any package in the
list, that package doesn't depend on any packages to the left of it
in the list. This ordering property is used to check for builtin
packages in the correct order. The problem was that including a
buildlink3.mk file for <pkg> correctly ensured that <pkg> was removed
from BUILDLINK_PACKAGES and appended to the end. However, since the
inclusion of any other buildlink3.mk files within that buildlink3.mk
was in a region that was protected against multiple inclusion, those
dependencies weren't also moved to the end of BUILDLINK_PACKAGES.
1.1.3:
Now with shiny new Hspell support (requires hspell
0.7). Other than that, no changes have been made since
the 1.1.2 release.
1.1.2:
Has Jordi's Ispell bugfix in it plus the new Hspell
backend.
1.1.0:
New Enchant release. This fixes some
ispell-compatibility mode problems (i.e. the command
line program), specifically related to charsets.
This also fixes some other charset issues that
affected our Ispell and Myspell backends. Big thanks
to Raphael Finkel and egmont@uhulinux.hu (Egmont
Koblinger)
Everyone is strongly encouraged to upgrade. It exports
1 more function and maintains API/ABI compability.
AbiWord 2.1.0 depends on this released version or a
CVS equivalent.
1.0:
:)
The project aims to provide an efficient extensible abstraction
for dealing with different spell checking libraries.
Enchant is meant to provide a generic interface into various existing
spell checking libaries. These include, but are not limited to:
* Aspell/Pspell
* Ispell
* Hspell
* Uspell
Enchant is also meant to be used in a cross-platform (XP) environment.
Part of this means that Enchant wants to limit its number of external
dependencies to 0, or as close is as humanly possible. Also, any
enchant consumer (i.e. a Word Processor) should not need to know
about what backend providers Enchant knows about. In fact, Enchant
shouldn't even need to know this information itself. To accomplish
this, all of Enchant's providers are DLLs.
Enchant is also meant to be used in a multi-user environment, such
as Unix. It is preferable to have both a $USER and a $GLOBAL
location for both provider DLLs and for dictionaries themselves,
when possible. Enchant's DLL location algorithm takes this into
account, and gives preference to the $USER DLLs, when found.
