Age | Commit message (Collapse) | Author | Files | Lines |
|
file's sole purpose was to provide a dependency on pkg-config and set
some environment variables. Instead, turn pkg-config into a "tool"
in the tools framework, where the pkg-config wrapper automatically
adds PKG_CONFIG_LIBDIR to the environment before invoking the real
pkg-config.
For all package Makefiles that included pkg-config/buildlink3.mk, remove
that inclusion and replace it with USE_TOOLS+=pkg-config.
|
|
No PKGREVISION bump since pkg-config is only a BUILD_DEPENDS.
|
|
This release features the ability to get a list of supported
languages, and the usual bugfixes. A few APIs have been deprecated
in the process.
|
|
|
|
|
|
CFLAGS.SunOS+= -D__EXTENSIONS__
This fixes problem where some definitions from <unistd.h>
were not used.
|
|
Bug fixes and better Mac OSX integration.
|
|
|
|
Since dependencies were actually failing to build, they fortunately don't
require PKGREVISION bumps themselves.
|
|
in the process. (More information on tech-pkg.)
Bump PKGREVISION and BUILDLINK_DEPENDS of all packages using libtool and
installing .la files.
Bump PKGREVISION (only) of all packages depending directly on the above
via a buildlink3 include.
|
|
All library names listed by *.la files no longer need to be listed
in the PLIST, e.g., instead of:
lib/libfoo.a
lib/libfoo.la
lib/libfoo.so
lib/libfoo.so.0
lib/libfoo.so.0.1
one simply needs:
lib/libfoo.la
and bsd.pkg.mk will automatically ensure that the additional library
names are listed in the installed package +CONTENTS file.
Also make LIBTOOLIZE_PLIST default to "yes".
|
|
|
|
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.
|
|
buildlink3.mk file in revision 1.101 of bsd.buildlink3.mk.
|
|
|
|
|
|
|
|
relative to ${WRKSRC}. Remove redundant LIBTOOL_OVERRIDE settings that
are automatically handled by the default setting in bsd.pkg.mk.
|
|
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.
|