1) Link with the wayland-egl library, but do so only if we determine that we
have Wayland support in the GDK backend with a compile test.
2) Provide a way to force disable the EGL backend.
Add a build option (--disable-pic, wxBUILD_PIC=OFF) to disable it.
Note that it is always enabled for shared libraries and static third party libraries.
This has been broken by the wrong test added in 13b0981eb9 (Get rid of
WXCONFIG_ONLY_CPPFLAGS variable in configure, 2020-02-02), which was
always false because it tested literal "SHARED" instead of the value of
the variable with this name.
This went unnoticed because WXUSINGDLL is not really necessary anyhow
under Unix, but it broke the build of any project building MSW binaries
using wx-config.
Commit 0fe1146b19 (Cache the result of inotify check in configure,
2020-04-15) was wrong as it defined wxHAS_INOTIFY inside the
AC_CACHE_CHECK(), meaning that this wasn't done at all if the value was
already cached.
Fix this by crrectly defining wxHAS_INOTIFY if inotify() availability
was either detected or cached.
Use non-standard but convenient AX_SUBDIRS_CONFIGURE() macro instead of
the standard AC_CONFIG_SUBDIRS() for libtiff, in order to allow passing
extra options to this sub-configure script without affecting any other
sub-configure ones and also without wrongly caching these options as
part of the main configure options, as happened before.
This notably fixes the problem with running "config.status", which
complained about unknown "--disable-jbig" and similar options, as they
were cached by the previous configure run.
We could also manually remove these options from ac_configure_args, but
doing it like this seems cleaner and simpler.
Since the changes of ef2b015e39 (Export CC and similar variables for
sub-configure scripts, 2018-10-20), using "-C" option with configure
didn't work any longer when also using built-in libtiff or expat, as
their configure scripts aborted due to detecting inconsistent build
environment because the values of exported CC etc variables they saw
differed from the values in the cache file.
Fixing this seems to be difficult, as we'd need to update the cache
before running the sub-configure scripts (which is simple enough), but
also remove the cached entries from it after doing it, as otherwise we'd
get the same inconsistent build environment problem simply by running
"configure -C" without any other options twice in a row, because the
first run would cache CC=gcc etc.
So work around this instead by disabling cache when exporting these
variables. And to make this workaround less annoying, restrict it to
only the cases when it's really needed, i.e. when we do modify these
variables in a non-trivial way.
With these changes, "configure -C" works again, but only uses caching if
possible.
Abort configure run with an error if a 3rd party library doesn't seem to
be present, when it's supposed to be used during the build, as this is
better than postponing the error until make runs into it much later and
also allows us to give a hopefully helpful message telling people that
they might be missing the relevant submodules.
Also add --disable-tests configure option to allow skipping building
tests entirely. In particular, this allows to avoid cloning any
submodules at all when using system libraries on a Unix system.
Closes https://github.com/wxWidgets/wxWidgets/pull/1954
Targeting anything less than 10.10 is not supported any longer, so check
for this and also update --with-macosx-version-min description in help
to mention it.
Mention the configure options to use to correct the problem explicitly.
Also restore the use AC_MSG_FAILURE() instead of AC_MSG_ERROR(), this
was originally correct and just the calls to exit() were unnecessary.
Verify that we're using a supported version of SDK and further improve
the error message if building a test program fails to mention that Xcode
7.3 or later is required.
Telling people to try using a different SDK was rather confusing if they
didn't specify any SDK in the first place and not very helpful if the
problem was due to specifying an incompatible minimum OS version, so fix
both problems at once by using the appropriate error message depending
on the configure options actually used.
The changes of 273e2e7343 (Remove duplicated flags from
{C,CPP,CXX,LD}FLAGS in configure, 2020-02-12) took care to leave
multiple -framework flags in LDFLAGS because removing them would be
wrong, but we also need to avoid removing -arch flags, that can possibly
appear multiple times (when using universal binaries) as well.
Change dedup_flags() itself to keep a list of exceptions to pass through
without checking that they're unique. If this list becomes longer in the
future, we could use an array and use "$0 in array" instead of multiple
"==" checks, but for now keep things simple.
Now that desktop Macs using ARM exist, we should default to building the
normal, macOS-targeting, port on them and not wxiOS any more.
This is a backwards incompatible change, but it shouldn't affect many
people, so should hopefully be fine.
This code never worked (as proved by the conversion in it which was
wrong by a factor of 1e12) and should never be needed anyhow.
Simplify configure and give an error, not warning, if neither
nanosleep() nor usleep() are available, as otherwise we'd just get a
build error later when compiling utilsunx.cpp later.
We need to ensure the configure arguments to disable features
are passed in immediately before calling, because the builtin
is the fallback if the system library is not found.
Fixes#18791
Remove separate checks for dlerror() which don't seem to be needed under
any platform any longer.
No real changes, just slim down configure/CMake a tiny bit.
This function is not used any more since e289eb07e1 (Get rid of
non-POSIX code for loading dynlibs on *nix, 2020-05-13), so don't check
for it and don't defined the corresponding HAVE_SHL_LOAD symbol.
A libinotify compatibility library exists for BSD systems. If this
was installed, configure would find sys/inotify.h but the build
would fail to link unless the library was added to the link line.
By also checking for inotify_init() this problem can be avoided.
Given that there is native support for kqueue, there is no need
to handle linking with libinotify.
This results in much shorter compilation lines and hence much shorter
build logs, which makes examining them simpler.
There should be no real changes, as we should never use duplicated
options intentionally.
CPPFLAGS, CFLAGS, CXXFLAGS and LDFLAGS are supposed to be under
user-control and putting configure-determined options in them broke
something as simple as running "make CXXFLAGS=-Wno-some-extra-warning"
because this overrode the CXXFLAGS set by configure and required for
build.
Improve this by using WX_*FLAGS in the generated makefile and leaving
the user-controlled FLAGS alone. This is still not ideal as running
"configure CFLAGS=-DFOO" and then "make CFLAGS=-DBAR" will define both
FOO and BAR, as configure copies CFLAGS to WX_CFLAGS, and so setting it
on make command line won't override it, as it should, but this should be
a much more rare and also much less severe problem, so we should be able
to live with it for now.
Normally this commit shouldn't result in any user-visible changes, i.e.
it shouldn't break any previously working scenarios and only make some
previously broken ones work.
It defaults to 1, but can be set to 0 to force using the generic version
of the control even under GTK or Mac, where the native version is used
by default.
This can, unfortunately, be useful to work around various but multiple
native control limitations.
This breaks Mac build by default and shouldn't be done. In fact, Cairo
should be used only optionally under MSW and Mac, where it's not always
needed, so add a new configure option to request it.
This is unnecessary, this header should always be available, so it was a
waste of time to check for it at best and, actually, this broke the
Cygwin build under AppVeyor as configure didn't find the header somehow,
even if compiling the code using it works perfectly well.
