Now with librsvg no longer used, and liblangtag no longer using glib,
a bunch of bundled (in some configurations, always on some platforms)
3rd-party libraries are no longer needed.
Initial work by rene, continued by tml.
Change-Id: I76edd7aea5452e3487499f0b9ed9f767cf760194
peter's gbuildifications caused and ocean of red, that
1/ was not followed up by any attempt by the author to fix
2/ I wasted a good part of the weekend to de-entangle with
only partial sucess
reverting the whole mess for now...
to be resubmited when a bit less borked...
This reverts commit c4c160a451.
This reverts commit faef2e51d0.
This reverts commit 057ce1fe29.
This reverts commit a7d34af344.
This reverts commit befae0ceb8.
This reverts commit 433b43bcd2.
This reverts commit 93e2c4a9d2.
The problem us that gb_LinkTarget__use_curl only declared a dependency
on an *unpacked* curl tarball, but the curlbuild.h file is *generated*
during curl configury. So something that depends on a (non-system)
curl needs to depend on curl having been configured at least. Let's
try like this.
Change-Id: I87b2a3292807d9bb873c3656caf58c4d98d8f622
Two different xmlparse libraries are created: ascii_expat_xmlparse and
expat_xmlparse. One without -DXML_UNICODE and one with. Source file are
duplicated and renamed with gb_UnpackedTarball_set_post_action function
to be able to add artifacts twice to gbuild machinery.
On windows 64 bit additional two librares are created: expat_xmlparse_x64 and
expat_xmltok_x64. That is due the problem with shell/shlxthandler (comment):
------------------------------------------------------
use UNICODE only because shell/shlxthandler
doesn't link against ascii_expat_xmlparse
------------------------------------------------------
Include files are delivered to $(OUTDIR)/inc/external/expat
now and not to $(OUTDIR)/inc/external any more.
set_include call is added in RepositoryExternal.mk.
To define dependency between StaticLibrary and ExternalProject
new function was introduced: gb_StaticLibrary_use_external_project.
Change-Id: I3b3aa40f39ef82c70f6f28790b582c83e48bdf76
Or rather, re-purpose that for consistency (and rename original to
gb_ExternalProject_use_external_project), to abstract over the
system/internal status of dependencies of external projects.
Use it in libcdr and replace exisiting uses in apache-commons.
Change-Id: Ie144600688fa884b5b6faa986c6b95bdfc1ee15c
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
There are currently 3 different mechanisms being used for frameworks,
which is of course intolerable so we invent a 4th one and standardize on
it: gb_LinkTarget_use_darwin_frameworks
(This doesn't mean using add_libs or externals was wrong, it was just
inconsistent... and i don't see an obvious benefit of using externals here)
Change-Id: I5de9020402c87e7236c6a358c47f02fa56642d3d
Move libraries using those headers to RepositoryExternal.mk and
also move pkg-config invocation to configure.
Change-Id: I17a240fcba83a98f3f248f15b34d245f941c62e2
such as wpd, it is necessary to depend on the package in the "use".
(for libraries built with gbuilt that is done automagically).
Change-Id: I022b66f679fe168de77c2481e6889cddbb0aac3c
regression from 22f2e5f286
so, lets follow the same pattern as else where and fixup
ENABLE_CUPS to be TRUE when enabled and lets just link
against cups and not do the dlopen dance
Change-Id: I3cff1bd98a7474c403d7ff66183e76e26e407de8
