[Swig-devel] Doxygen changes. Was: generate type hints for python 3.5+

[William S Fulton]

Hello William,
This is another (last?) plea for integrating the doxygen branch before
making these changes as they would certainly result in a lot of conflicts
with the changes done there. I definitely agree that new features are nice,
but it would be great if the already implemented "old" features could be
made part of the official version too.

Hi Vadim

You're very patient and I've been slow on the uptake of the doxygen
branch since your last round of changes for which I apologise. My free
time at the moment is limited, but a quick scan of the doxygen branch
looks okay now. I'd like the code to better conform to the SWIG style,
but don't see that as being too hard. I'd rather not have all the STL
dependencies and originally planned to fix these myself, but I don't
really have the time right now. I'd say in total though the changes
are too much for the finally stable 3.0.x releases. Let's start
thinking about a 3.1.0 release to include doxygen support. How does
that sound?

I think the 3.1.0 version should also remove some legacy support too
that we don't want, in particular, dropping Python support prior to
2.2 or maybe 2.4. There are lots of options for Python which are
becoming a maintenance headache and so I suggest we drop as many of
these as possible and turn them on by default. We have a window for a
new release series to put in anything else that is a risky change, so
if anyone can think of anything else speak up.

William

------------------------------------------------------------------------------

[Marko Klopcic]

Hi,

I also vote for integrating the doxygen branch. I did some coding on it
three years ago,
and it works fine for my types of comments.

Marko

Post by William S Fulton

Hello William,
This is another (last?) plea for integrating the doxygen branch before
making these changes as they would certainly result in a lot of conflicts
with the changes done there. I definitely agree that new features are nice,
but it would be great if the already implemented "old" features could be
made part of the official version too.

Hi Vadim
You're very patient and I've been slow on the uptake of the doxygen
branch since your last round of changes for which I apologise. My free
time at the moment is limited, but a quick scan of the doxygen branch
looks okay now. I'd like the code to better conform to the SWIG style,
but don't see that as being too hard. I'd rather not have all the STL
dependencies and originally planned to fix these myself, but I don't
really have the time right now. I'd say in total though the changes
are too much for the finally stable 3.0.x releases. Let's start
thinking about a 3.1.0 release to include doxygen support. How does
that sound?
I think the 3.1.0 version should also remove some legacy support too
that we don't want, in particular, dropping Python support prior to
2.2 or maybe 2.4. There are lots of options for Python which are
becoming a maintenance headache and so I suggest we drop as many of
these as possible and turn them on by default. We have a window for a
new release series to put in anything else that is a risky change, so
if anyone can think of anything else speak up.
William
------------------------------------------------------------------------------
_______________________________________________
Swig-devel mailing list
https://lists.sourceforge.net/lists/listinfo/swig-devel

[Vadim Zeitlin]

On Thu, 7 Jan 2016 07:59:49 +0000 William S Fulton <***@fultondesigns.co.uk> wrote:

WSF> You're very patient and I've been slow on the uptake of the doxygen
WSF> branch since your last round of changes for which I apologise. My free
WSF> time at the moment is limited, but a quick scan of the doxygen branch
WSF> looks okay now. I'd like the code to better conform to the SWIG style,
WSF> but don't see that as being too hard. I'd rather not have all the STL
WSF> dependencies and originally planned to fix these myself, but I don't
WSF> really have the time right now.

Hi,

Unfortunately it's exactly the same thing for me. I did the original work
as part of my work because we needed to produce documentation for the
Python wrappers of our library, but I can't really justify redoing the code
style (which is, I agree, ugly and inconsistent with the rest of SWIG) or
getting rid of the STL (which I'm much less sure about, I definitely prefer
working with the STL code rather than DOH, the only problem here is the
inconsistency but I'd rather live with it) on the clients time. And I just
don't foresee having enough of free time of my own to do this in the next
couple of decades.

WSF> I'd say in total though the changes are too much for the finally
WSF> stable 3.0.x releases. Let's start thinking about a 3.1.0 release to
WSF> include doxygen support. How does that sound?

Sure, this is a big change and does merit a minor version bump. The
important thing IMO me is to get this merged so that it could be further
improved later. Personally, I can't really motivate myself to get back to
it until it happens, I've been trying to get it merged since almost 2 years
by now...

WSF> I think the 3.1.0 version should also remove some legacy support too
WSF> that we don't want, in particular, dropping Python support prior to
WSF> 2.2 or maybe 2.4.

Honestly, I think we could limit the support to just 2.6 and 3.x (with
some x>0, probably, but I'm not sure what's the situation with the 3.x
adoption exactly) and this wouldn't be a problem at all. 2.6 unfortunately
is still alive on some RHEL systems, otherwise I'd even argue for limiting
Python support to 2.7 only. But then there is not much difference, at C API
level, between 2.6 and 2.7, unlike with 2.4 or 2.2 and absolutely nobody
uses these old Python versions by now.

Regards,
VZ

[Kris Thielemans]

Hi

Just to say that I think using STL (a standard) is a better idea than using
DOH (a home-grown library that makes it very hard to debug things). But as
my contributions to SWIG are tiny, feel free to ignore me!

Kris

[Marko Klopcic]

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j

[Vadim Zeitlin]

On Tue, 10 May 2016 13:00:54 +0200 Marko Klopcic <***@isystem.si> wrote:

MK> What is the status of doxygen branch?

Nothing has changed since the last time this was discussed.

MK> Could someone merge latest release (3.0.8) to this branch, if the
MK> branch can't get to master?

I'll probably try doing it sooner or later, but it risks being non trivial
because there have been quite a few changes to Python module in the master.
If anybody else wants to try doing the merge, feel free to submit PRs to
the doxygen branch in my own SWIG fork, I can at least promise to apply
them quickly.

Regards,
VZ