[Swig-devel] Extension for generated C++ files

[Olly Betts]

Currently the extension for generated C++ files is ".cxx" for all languages
except for PHP where it's ".cpp" (there is no good reason for this divergence
that I'm aware of - tracking the change back it appears to come from
"The great merge" back in 2002).

You can change this for PHP with:

swig -php -cppext cc

And in fact our own testsuite uses this to change the extension back to cxx!

For Ocaml we provide an option with the same effect, but a different name:

swig -ocaml -suffix cc

For other languages you can't change the extension directly, but you can
specify a filename with extension using -o:

swig -python -o foo_wrap.cc

The current situation seems less than ideal to me, but I thought I should
canvas opinions rather than just changing things.

I think it is useful to be able to specify the extension, as some compilers
and build tools are fussy about it, and there's no good reason why this
shouldn't be supported for all backends. That would just be a matter of
moving the code which handles this option, as it just calls
SWIG_config_cppext(ext).

I think -cppext is a better name than -suffix - (particularly as this is
only used for C++ files), so I propose that -suffix remain supported for
now as an Ocaml-specific option, but prints a warning that it is deprecated
and that -cppext is preferred as of SWIG 3.0.4 (or whatever version).

I don't like the PHP backend having a different default, though changing
that is an incompatible change for anyone generating PHP bindings and not
using -cppext or -o.

Cheers,
Olly

[William S Fulton]

Post by Olly Betts
Currently the extension for generated C++ files is ".cxx" for all languages
except for PHP where it's ".cpp" (there is no good reason for this divergence
that I'm aware of - tracking the change back it appears to come from
"The great merge" back in 2002).
swig -php -cppext cc
And in fact our own testsuite uses this to change the extension back to cxx!
swig -ocaml -suffix cc
For other languages you can't change the extension directly, but you can
swig -python -o foo_wrap.cc
The current situation seems less than ideal to me, but I thought I should
canvas opinions rather than just changing things.
I think it is useful to be able to specify the extension, as some compilers
and build tools are fussy about it, and there's no good reason why this
shouldn't be supported for all backends. That would just be a matter of
moving the code which handles this option, as it just calls
SWIG_config_cppext(ext).
I think -cppext is a better name than -suffix - (particularly as this is
only used for C++ files), so I propose that -suffix remain supported for
now as an Ocaml-specific option, but prints a warning that it is deprecated
and that -cppext is preferred as of SWIG 3.0.4 (or whatever version).
I don't like the PHP backend having a different default, though changing
that is an incompatible change for anyone generating PHP bindings and not
using -cppext or -o.
Agreed a consistent approach is best. Let's go for -cppext for all

languages. A deprecated warning for ocaml is fine too. Please also modify
the html manual appropriately.

William

[Olly Betts]

Post by Olly Betts

Post by Olly Betts
I think -cppext is a better name than -suffix - (particularly as this is
only used for C++ files), so I propose that -suffix remain supported for
now as an Ocaml-specific option, but prints a warning that it is deprecated
and that -cppext is preferred as of SWIG 3.0.4 (or whatever version).
I don't like the PHP backend having a different default, though changing
that is an incompatible change for anyone generating PHP bindings and not
using -cppext or -o.

Agreed a consistent approach is best. Let's go for -cppext for all
languages. A deprecated warning for ocaml is fine too. Please also modify
the html manual appropriately.

Done.

What do you think about making the PHP backend default to "cxx" like all
the other backends?

The different default is an ugly and pointless difference, but if we're
going to change it I guess we should first add a warning if the default
extension ends up used when PHP is in use (something like if -cppext or
-o isn't used), which will give people a chance to update invocations
such that they don't depend on the current default, then later (probably
at the next major version bump) actually change the default.

That's workable, but does require action from a subset of users -
looking at codesearch.debian.net suggests a bit under half, but that
may not be a representative sample.

Cheers,
Olly

[William S Fulton]

Post by Olly Betts

Post by Olly Betts

Post by Olly Betts
I think -cppext is a better name than -suffix - (particularly as this is
only used for C++ files), so I propose that -suffix remain supported for
now as an Ocaml-specific option, but prints a warning that it is deprecated
and that -cppext is preferred as of SWIG 3.0.4 (or whatever version).
I don't like the PHP backend having a different default, though changing
that is an incompatible change for anyone generating PHP bindings and not
using -cppext or -o.

Agreed a consistent approach is best. Let's go for -cppext for all
languages. A deprecated warning for ocaml is fine too. Please also modify
the html manual appropriately.

Done.
What do you think about making the PHP backend default to "cxx" like all
the other backends?
The different default is an ugly and pointless difference, but if we're
going to change it I guess we should first add a warning if the default
extension ends up used when PHP is in use (something like if -cppext or
-o isn't used), which will give people a chance to update invocations
such that they don't depend on the current default, then later (probably
at the next major version bump) actually change the default.
That's workable, but does require action from a subset of users -
looking at codesearch.debian.net suggests a bit under half, but that
may not be a representative sample.

I'd be happy with changing the default to .cxx and agree that this
should not occur in the 3.0.x point releases. It would have to wait
for 3.1 (but I don't know when that'll happen!). I don't know that a
warning is a good idea before then. A lot of folk like to keep it
simple without specifying -o and warning will be a bit unnecessary for
those who will easily change their build system and like to keep the
same options for multiple languages (and -cppext doesn't work for
older versions except php). I don't know! Transitioning to a new
default is tricky, there isn't any particularly smooth route.

William

[Olly Betts]

Post by William S Fulton

Post by Olly Betts
What do you think about making the PHP backend default to "cxx" like all
the other backends?
The different default is an ugly and pointless difference, but if we're
going to change it I guess we should first add a warning if the default
extension ends up used when PHP is in use (something like if -cppext or
-o isn't used), which will give people a chance to update invocations
such that they don't depend on the current default, then later (probably
at the next major version bump) actually change the default.
That's workable, but does require action from a subset of users -
looking at codesearch.debian.net suggests a bit under half, but that
may not be a representative sample.

I'd be happy with changing the default to .cxx and agree that this
should not occur in the 3.0.x point releases. It would have to wait
for 3.1 (but I don't know when that'll happen!). I don't know that a
warning is a good idea before then. A lot of folk like to keep it
simple without specifying -o and warning will be a bit unnecessary for
those who will easily change their build system and like to keep the
same options for multiple languages (and -cppext doesn't work for
older versions except php). I don't know! Transitioning to a new
default is tricky, there isn't any particularly smooth route.

You can't actually use exactly the same options for multiple languages -
trivially so since e.g. Python requires -python while PHP requires -php.

So any build system attempting this will need to have language-specific
SWIG flags already (and you're probably going to want to pass other
language-specific options somewhere anyway - looking at Xapian's
bindings, we're passing such options for csharp, java, perl, php,
python, ruby, and tcl8 - it's only lua where we only have generic
options aside from -lua).

Also, any build system with common rules will have to deal with the
generated wrapper for PHP being foo_wrap.cpp instead of foo_wrap.cxx for
other languages!

But I'm OK with just changing it for 3.1.0 (or 4.0.0 if we do that
instead).

Cheers,
Olly