Re: Introduce wxwidgets 3.3 devel branch releases to ports

Nuno Teixeira <[email protected]>
Newsgroups gmane.os.freebsd.desktop,gmane.os.freebsd.devel.ports
Message-ID <CAFDf7UJGqL21ZhO4c3mfLk2PgwC8mS426cLnqgkWVk8ifN+Lag@mail.gmail.com>
Hello,

I did some work on 3.3. It builds ok.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288467

Cheers,

Chris <[email protected]> escreveu (sexta, 25/07/2025 à(s) 00:13):

> On 2025-07-24 11:28, Nuno Teixeira wrote:
> > Hello,
> >
> > 3.3 branch means devel branch and upstream have released 3.3.0 and 3.3.1.
> > Repology shows that 2 or 3 linux distros are using 3.3 branch.
> > The only consumer for 3.3 is deskutils/treesheets.
> >
> > I will continue my builds with 3.3.1 with cmake as recomended upstream
> and
> > soon I will open an PR so people can take a look.
> >
> > One doubt that I have is should we use 'devel' or 3.3 when changing
> > Mk/bsd.wx.mk...
> IMHO 3.3 would be the best choice. Default already being 3.2. It only
> provides a newer version to test against. Not unlike you're doing
> w/treesheets.
> I don't see it as being any different than, php, perl, and several other
> ports.
> The nice thing about this approach, is it's easy for maintainers to test
> against,
> having  specific version to work with. Rather than "devel", which isn't
> very
> specific/obvious.
>
> >
> > Other thing, I will need help on Mk/bsd.wx.mk because I have some
> > dificulties. With some help from AI I'm will use bellow diff for some
> tests:
> >
> > --- a/Mk/bsd.wx.mk
> > +++ b/Mk/bsd.wx.mk
> > @@ -107,8 +107,8 @@
> >
> >  _WX_COMPS_ALL= wx python
> >  _WX_DEP_TYPES_ALL= build lib run
> > -_WX_VERS_ALL= 3.0 3.2
> > -_WX_VERS_UC_ALL= 3.0 3.2
> > +_WX_VERS_ALL= 3.0 3.2 3.3
> > +_WX_VERS_UC_ALL= 3.0 3.2 3.3
> >  _WX_VERS_SKIP= 3.0 3.2
> >  _WX_VERS_LISTS= WANT_WX_VER WITH_WX_VER _WX_VER_INSTALLED
> >
> > @@ -129,6 +129,12 @@
> >  _WX_PORT_wx_3.2= x11-toolkits/wxgtk32@${_GTKFLAVOR}
> >  _WX_LIB_wx_3.2= wx_baseu-3.2
> >
> > +# wxgtk 3.3 (para wxWidgets 3.3.1 devel)
> > +_WX_PORT_wx_3.3= x11-toolkits/wxgtk33@${_GTKFLAVOR}
> > +_WX_LIB_wx_3.3= wx_baseu-3.3
> > +_WX_PORT_python_3.3= x11-toolkits/py-wxPython4@${PY_FLAVOR}
> > +_WX_FILE_python_3.3= ${PYTHON_SITELIBDIR}/wx/__init__.py
> > +
> >  # Set _WX_SHVER_comp_ver to 0 and _WX_FILE_comp_ver for libs
> appropriately.
> >  # Set _WX_DEPTYPE_comp_ver for "python" to "run", and others to "lib".
> >
> > Cheers,
> >
> >
> > Chris <[email protected]> escreveu (quinta, 24/07/2025 à(s)
> 16:33):
> >
> >> On 2025-07-23 12:37, Nuno Teixeira wrote:
> >> > [Resending mail as it didn't reach lists]
> >> >
> >> > Hello,
> >> >
> >> > I'd like to have some advise about the possibility of adding wx 3.3
> devel
> >> > branch releases to ports as I see at least one port moving in that
> >> > direction.
> >> Given wxgtk is @ 3.2. Seems like the best options are
> >> 1. Open a pr(1) (bugzilla) with a patch to upgrade wxwidgets to 3.3
> >> 2. Do the same, but instead, add wxwidgets verison 3.3
> >> It's not uncommon to have a couple of versions of the same port in the
> >> tree -- Perl, PHP for example.
> >> But unless there are any major changes that break dependent ports. I
> think
> >> option 1 would probably be the best approach.
> >> >
> >> > One thing that I don't understand is why some upstream projects just
> jump
> >> > to devel dependencies leaving no support to stable branches...
> >> >
> >> > Please take a look at:
> >> >
> >>
> https://github.com/aardappel/treesheets/issues/1064#issuecomment-3106748619
> >> >
> >> > At this point, treesheets will be in stale status and I don't know
> what
> >> to
> >> > do:
> >> > add wx 3.3 port or deprecate treesheets...
> >> >
> >> > Any hints are welcome,
> >> >
> >> > Thanks,
> >>
> >> --Chris
> >> --
> >> Sent from hardware running on and written by FreeBSD.
>
> --
> --
> Sent from hardware running on and written by FreeBSD.



-- 
Nuno Teixeira
FreeBSD UNIX:  <[email protected]>   Web:  https://FreeBSD.org
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.