This does remove the net* commands from the
Unix version that may return at a later date
with OSX and Windows support.
This commit also makes numerious other changes
such as code cleanup, reformatting, etc.
Closes#829
- Store openssl flags in own vars
- Share some common flags for plugins
- Fix building plugins on win32
- Store all glib flags in one var
- Don't link against every lib for each plugin
- Don't hardcode ldflags for sysinfo
- Fixes support for large files.
- Fixes filenames not being passed in the filename encoding.
- Drops openssl dependency.
- Code cleanup.
- Fix 'unknown command' warning.
To anybody confused this is not the next stable release, it is just a way to differentiate master
from the 2.10 branch and next stable will be 2.12.0 similar to Gnome's versioning scheme.
- add checks for python3.4
- only warn once for failure to find a version
- only run pkg-config call if the .pc file was actually found
- make unsupported python version non-fatal
Closes#1006Closes#989
- openSUSE has ExtUtils::Embed, EXTERN.h and perl.so in the base perl package.
- Fedora has ExtUtils::Embed in a separate perl-devel package.
- Mageia has ExtUtils::Embed in the base perl package but EXTERN.h in a separate perl-devel package. Without this package, the compiler complains about the missing header.
- Debian has ExtUtils::Embed and EXTERN.h in the base perl package but perl.so in a separate libperl-dev package. Without this package, gcc compiles successfully but complains at link-time about -lperl (ExtUtils::Embed returns '-lperl' in ldopts but it's not actually installed).
configure.ac already requires ExtUtil::Embed to enable perl. To handle the case of Mageia and Debian, this change uses AC_TRY_LINK to verify that the flags returned by ExtUtils::Embed can actually be used to compile before deciding to enable the perl plugin.
