ed289e0577 UseSWIG: Use CSharp language only if it is enabled
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ram-Z <me@rmz.io>
Acked-by: Marc Chevrier <marc.chevrier@gmail.com>
Merge-request: !2219
In commit v3.12.0-rc1~2^2 (UseSWIG: Add CSHARP variant for wrapper
files, 2018-06-08) we explicitly marked swig-generated `.cs` files as
`LANGUAGE` CSharp so that the resulting sources can be compiled.
However, this works only when the CSharp language has been enabled.
Fixes: #18184
Fix a typo from commit 0bef9eb410 (UseSWIG: modernize module,
2018-01-29) that caused `UseSWIG` to ignore an eventually set property
`SWIG_MODLUE_NAME`.
Building multiple python modules using the mentioned property as
described in the docs could lead to an invalid, or even worse,
inconsistent `build.ninja` file. The reason is that the generated list
of support files was not unique. For each module the support file was
always named the same, namely `path/to/builddir/MODULENAME.py`.
Fix logic added by commit 2ee10119ea (swig: fix incremental build in
case of removed interface files, 2017-11-06). Name the extra targets
added for Makefile generators using both the module name and .i base
name to avoid collisions across modules. Also make sure the extra
targets added for all .i files in a module are added as dependencies
instead of just the last one.
Fixes: #17704
The `SWIG_OUTFILE_DIR` variable provides the option to specify an output
directory location. This commit removes portion stating that this is
equal to the `swig -o` option since it does not set the output filename.
Fixes: #17703
Signed-off-by: Noel Eck <noel.eck@intel.com>
Commit v3.8.0-rc1~123^2 (UseSWIG: Automatically scan dependencies of SWIG files
for Makefiles, 2016-12-21) introduced automatic dependency scanning for files
`%include`d in a swig interface definition file. This works fine as long as no
such file is removed. But removing a dependent file breaks an incremental build
and `make` complains about a missing dependency, see #16830.
Integrate the approach proposed in the issue above into the SWIG-module, do the
workaround in a conditional step as it arises only for Makefile generators. For
other generators use the implementation before that commit.
Fixes: #17433.
Since commit v3.8.0-rc1~251^2 (UseSWIG: Record generated java files as
custom command outputs, 2016-11-28) the generated `.java` files are
listed as sources in the call to `add_library` by swig_add_library.
They are listed only as the outputs of custom commands and not intended
for compilation as part of the library.
Reported-by: Alan W. Irwin <irwin@beluga.phys.uvic.ca>
SWIG fails with a redefined macro error when `-dllimport` is specified
more than once. One case where you would want to specify your own
dllimport is when using SWIG with netstandard2.0. .NET Core does not
search for shared library like Mono or .NET, so you need a fully
qualified shared library name.
Teach `SWIG_ADD_LIBRARY` to fall back to an empty library prefix for
languages we don't explicitly define already.
Suggested-by: Alan W. Irwin <irwin@beluga.phys.uvic.ca>
The cmake_parse_arguments command is builtin with version 3.5.
The CMakeParseArguments module is empty and exists for backwards
compatibility with CMake 3.4 and lower.
Remove the includes of CMakeParseArguments from CMake's modules.
The modules are always used with the current version of CMake.
Leave the includes in the tests, as the tests may be run with an older
version of CMake.
When another target depends on the generated files CMake must know which
custom command generates them in order to hook up the dependency
properly. We already do this for Python. Add the Java files too.
swig_add_module does not allow to set the type for the library and
instead always create the library as MODULE.
This patch adds the new swig_add_library command with this signature:
SWIG_ADD_LIBRARY(<name>
[TYPE <SHARED|MODULE|STATIC>]
LANGUAGE <language>
SOURCES <file>...
)
The swig_add_module is deprecated in favour of swig_add_library.
Closes: #16415
`swig` has two output-related options:
* `-o <outfile>`: Set name of C/C++ output file to <outfile>
* `-outdir <dir>`: Set language-specific files output directory to <dir>
We already have `CMAKE_SWIG_OUTDIR` for the latter. Add a new
`SWIG_OUTFILE_DIR` option for the former.
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
Generally for a module foo, SWIG generates (in Python mode)
an extension module _foo.so and a proxy Python module foo.py.
However, if -noproxy is specified, instead it builds only foo.so
(without the leading underscore). The custom command generated
by CMake correctly handles the removal of this underscore when
-noproxy is given; however, it still adds foo.py to the expected
outputs. This upsets build tools that expect foo.py to be generated
(for example, 'make' will run the SWIG command twice). Fix this
by removing foo.py from the set of extra generated files when
-noproxy is specified.
This reverts commit 242c3966 (add_custom_command: Diagnose
MAIN_DEPENDENCY limitation, 2015-03-09) and the follow up commit
b372a99a (UseSWIG: Do not use MAIN_DEPENDENCY on custom commands,
2015-03-26).
I misdiagnosed the underlying issue that prompted creation of policy CMP0057.
The actual issue surfaces when a single custom command's MAIN_DEPENDENCY
is listed in more than one target; this issue will have to be addressed
independently.
When SWIG_GET_EXTRA_OUTPUT_FILES checks to see if a source file exists
for use in reading the module name, it must pass an absolute path to
the if(EXISTS) command. Teach SWIG_ADD_SOURCE_TO_MODULE to give it
the absolute path it already knows.
Add the dependency on the main swig input source file as a normal
DEPENDS option. We cannot use MAIN_DEPENDENCY because if there are
multiple target languages then multiple custom commands would want to
use the same MAIN_DEPENDENCY, but at most one custom command may specify
a given source file as its MAIN_DEPENDENCY. Exposed by a CMP0057
warning.
Protect against variables named "CSHARP", "PERL", "PYTHON", or "UNKNOWN"
when CMP0054 is not set to NEW.
Reported-by: Tuukka Pasanen <tuukka@iocaste.ilmi.fi>
The check for this flag added by commit v3.0.0-rc1~284^2 (UseSWIG: Name
python module according to swig flags, 2013-11-26) can get false
positives on flags like "-noproxydel". Improve the check to match only
"-noproxy".
Suggested-by: Garth Wells <gnw20@cam.ac.uk>
