Add support so that the %csmethodmodifiers, %dmethodmodifiers,
%javamethodmodifiers can modify the method modifiers for the destructor wrappers
in the proxy class: dispose, Dispose, delete. With this feature, it is now possible
to make a C# proxy class sealed, eg when wrapping a class X, the virtual method modifiers
can be removed using:
%typemap(csclassmodifiers) X "public sealed class"
%csmethodmodifiers X::~X "public /*virtual*/";
Changes the location of the director code wrt to the generated _wrap.h
file to fix throw macro skullduggery in the director_throws testcase
(see previous commit).
Split director_exception testcase into two so that testing throw(),
with no arguments, that is nothrows, can be tested separately to throw()
taking arguments. [The throw keyword needs to be removed for C++
compilation in C++11 and later when it was deprecated.]
Some code in this test case is actually only supported in c++17...
cpp11_lambda_functions_wrap.cxx:275:87: error: the type ‘const<lambda(int, int)>’ of ‘constexpr’ variable ‘lambda18’ is not literal
CONSTEXPR auto lambda18 = [] (int x, int y) mutable TESTCASE_THROW(int) { return x+y; };
^
cpp11_lambda_functions_wrap.cxx:275:28: note: ‘<lambda(int, int)>’ is not literal because:
CONSTEXPR auto lambda18 = [] (int x, int y) mutable TESTCASE_THROW(int) { return x+y; };
^
cc1plus: note: ‘<lambda(int, int)>’ is a closure type, which is only literal in C++17 and later
cpp11_lambda_functions_wrap.cxx:278:89: error: the type ‘const Space1::<lambda(int, int)>’ of ‘constexpr’ variable ‘Space1::lambda19’ is not literal
CONSTEXPR auto lambda19 = [] (int x, int y) mutable TESTCASE_THROW(int) { return x+y; };
1. move the 'no executable found' message up to be with the executable tests
2. test for an (non-)empty GUILE variable for all other conditions after that
An empty GUILE variable means guile is disabled and consistently using the
same test makes the code more readable.
Querying guile-config for the executable name was only introduced in guile 2.0.12.
If it works it's the most reliable method in environments with more than one guile
executable. If it doesn't work fall back to path detection, assuming the executable
name is just 'guile'. If that's incorrect it's up to the caller to explicitly
specify the path to the right guile executable.
This allows to only specify --with-guile-config=xyz to configure and it will pick up
the correct guile executable in case more versions of guile are installed on the same
system. For example on Fedora 27, I have
/usr/bin/guile1.8
/usr/bin/guile (which is guile 2.0)
/usr/bin/guile2.2
Without this patch the configure script would always pick /usr/bin/guile regardless of which
guile-config I would specify (guile1.8-config, guile-config or guile-config2.2).
With the patch guile2.2 is now correctly picked for guile-config2.2.
Unfortunately it still won't work with guile 1.8 because that version can't provide the
executable name via guile-config yet. In that case configure will fall back to the old
behaviour. On my Fedora 27 system that would mean it would still pick the wrong
executable. However this is not critical because that as well can be overridden by
setting --with-guile=abc. I don't see an easy way to improve on this.
The condition only applies to guile 1.8 and older so it should really
have been '<2' all along. As we already have such a conditional block
earlier up, merge the two together as well.
We haven't uploaded the latest version of these scripts to ftp.gnu.org
in over 10 years. See ftp://ftp.gnu.org/pub/gnu/config/README. The
best place to fetch them from is the Savannah git repository.
