Suggestion for future versions for avoiding conflicts when installing different versions of the API

[Andriy Byelikov]

[resending since I found out that wx-discuss wasn't used]

Hi! I am developing an application using wxWidgets on Arch Linux and I noticed that the latest stable version 3.0.4 that Arch Linux (and probably many other distros) provide does not have XDG file layout support, so I switched to 3.1.4. However for application packaging it would be great to be able to provide a 3.1.x package to have access to the 3.1.x API. So I started investigating if it would be possible to keep a new package alongside the 3.0.x package, since applications that rely on 3.0.x such as Audacity still need this version. For header files and static and dynamic libraries this does not seem to be a problem since they contain the API version as part of their filename, so I diffed a 3.0.5 installation with a 3.1.4 installation and the following conflicts popped up:

Files 305/usr/local/bin/wx-config and 314/usr/local/bin/wx-config differ
Files 305/usr/local/bin/wxrc and 314/usr/local/bin/wxrc differ
Files 305/usr/local/share/aclocal/wxwin.m4 and 314/usr/local/share/aclocal/wxwin.m4 differ
Files 305/usr/local/share/bakefile/presets/wx.bkl and 314/usr/local/share/bakefile/presets/wx.bkl differ
Files 305/usr/local/share/bakefile/presets/wx_win32.bkl and 314/usr/local/share/bakefile/presets/wx_win32.bkl differ
Files 305/usr/local/share/bakefile/presets/wx_xrc.bkl and 314/usr/local/share/bakefile/presets/wx_xrc.bkl differ
Files 305/usr/local/share/locale/ca/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/ca/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/cs/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/cs/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/da/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/da/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/de/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/de/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/el/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/el/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/es/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/es/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/fi/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/fi/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/fr/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/fr/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/hu/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/hu/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/id/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/id/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/it/LC_MESSAGES/wxmsw.mo and 314/usr/local/share/locale/it/LC_MESSAGES/wxmsw.mo differ
Files 305/usr/local/share/locale/it/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/it/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/ja/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/ja/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/nl/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/nl/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/pl/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/pl/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/ru/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/ru/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/sl/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/sl/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/sv/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/sv/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/tr/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/tr/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/uk/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/uk/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/zh_CN/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/zh_CN/LC_MESSAGES/wxstd.mo differ
Files 305/usr/local/share/locale/zh_TW/LC_MESSAGES/wxstd.mo and 314/usr/local/share/locale/zh_TW/LC_MESSAGES/wxstd.mo differ
My suggestion is that the wxWidgets developers (upstream) add some kind of version suffix to these conflicting files, including the wx-config script, as developers that invoke it probably know which version of the API they're developing on.

Also on the main page it is encouraged to use 3.1.4 for production.
Please notice that while 3.1.4 is officially a “development” version because it is not fully compatible with the “stable” 3.0.x, the list of backwards incompatible changes is very short, so you shouldn’t have any problems updating to this version from 3.0.x in practice, and you’re encouraged to use this release, including in production.
Since the "latest" stable API hasn't changed since 2013 and also moving forward I think this is a good way to address packaging if it also takes a long time to provide a fully stable API in the future. At least new application developers will be able to support the newer API.

Tell me what you think about it and if it is possible to do so I will relay it to the Arch Linux forums to create a new package for 3.1.x that does not conflict with 3.0.x.

[Vadim Zeitlin]

On Fri, 29 Jan 2021 22:30:21 -0800 (PST) Andriy Byelikov wrote:

AB> [resending since I found out that wx-discuss wasn't used]

Indeed, that list is supposed to be used for non-technical discussions and
we don't really have many of those.

AB> Hi! I am developing an application using wxWidgets on Arch Linux and I
AB> noticed that the latest stable version 3.0.4 that Arch Linux (and probably
AB> many other distros) provide does not have XDG file layout support, so I
AB> switched to 3.1.4. However for application packaging it would be great to
AB> be able to provide a 3.1.x package to have access to the 3.1.x API.

Yes, absolutely!

AB> started investigating if it would be possible to keep a new package
AB> alongside the 3.0.x package, since applications that rely on 3.0.x such as
AB> Audacity still need this version. For header files and static and dynamic
AB> libraries this does not seem to be a problem since they contain the API
AB> version as part of their filename, so I diffed a 3.0.5 installation with a
AB> 3.1.4 installation and the following conflicts popped up:
AB>
AB> Files 305/usr/local/bin/wx-config and 314/usr/local/bin/wx-config differ

This one is supposed to work, i.e. wx-config installed by any version
should still give access to the other installed versions. I don't know if
you can somehow indicate that you it's ok to overwrite the existing file
when installing the new one, but if you can, it should already work.

AB> Files 305/usr/local/bin/wxrc and 314/usr/local/bin/wxrc differ

I don't know what to do about this one. We really want to use just wxrc
(and not wxrc-3.1.4 or whatever) and we want it to be in the PATH. Using
the latest wxrc version should probably work with 3.0, but I'm not 100%
sure about this.

AB> Files 305/usr/local/share/aclocal/wxwin.m4 and
AB> 314/usr/local/share/aclocal/wxwin.m4 differ

Same as above. If you can just always install the latest version, it
should work. Otherwise I don't know.

AB> Files 305/usr/local/share/bakefile/presets/wx.bkl and
AB> 314/usr/local/share/bakefile/presets/wx.bkl differ

We don't really care about those, we probably could just stop installing
them or even remove them completely, I think...

AB> Files 305/usr/local/share/locale/ca/LC_MESSAGES/wxstd.mo and
AB> 314/usr/local/share/locale/ca/LC_MESSAGES/wxstd.mo differ
[...and many more...]

I guess we need to use version-specific suffix for those... Doing this
would require, of course, not just renaming them when installing, but also
modifying the catalog loading code to search for the versioned files. It
probably needs to be done, but I honestly have no idea who will have time
and motivation to do it. Any contributions would be very welcome.

AB> My suggestion is that the wxWidgets developers (upstream) add some kind of
AB> version suffix to these conflicting files, including the wx-config script,
AB> as developers that invoke it probably know which version of the API they're
AB> developing on.

We don't want to rename wx-config unless it's absolutely required...

AB> Tell me what you think about it and if it is possible to do so I will relay
AB> it to the Arch Linux forums to create a new package for 3.1.x that does not
AB> conflict with 3.0.x.

I'd very much like to see wx 3.1 packages, but I only see a good solution
for the message catalog files clash and not for the other ones. And even
for the message catalogs, seeing a solution is not quite the same as
actually implementing it...

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Andriy Byelikov]

Okay, after tinkering around for a while here's the follow-up.

Locale .mo files suffix issue:

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

I have created a patch for the 3.1.4 release, but I'm not sure if this is

all that needs to be done for programs to detect the .mo filles with the

suffix. What I did is to try to find all references to the "wxstd" catalog

file and to add the release suffix, but I did not find any references to

"wxmsw.mo" files. For the installation of these files, I modified the

"wx.bkl" bakefile adding the release suffix to the catalog files the and

regenerating the "Makefile.in". It made some more changes than what I

expected (replacing "dll" with "lib" in some places) so I only included

the ones I wanted in the Makefile.in part of the patch.

Here's the patch:

https://pastebin.com/FNK2ZtDq

I tried to test these changes by compiling the internat sample with the

new patched package that I built with the 3.1.4 release as the source.

I tried to run internat selecting the French locale and it seems to work.

But that is only representative if it actually uses the "wxstd-3.1.mo"

file. If someone who knows better about how the "wxstd.mo" catalogs are

used could test it it would be great.

"wx-config" and "wxrc" issue:

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

For "wx-config" and "wxrc" the simple solution is to add a "-3.1" suffix

to the filenames.

This is trivial for "wxrc" since it is agnostic of whether the build was

configured with GTK 2 or 3, so it would simply be installed as "wxrc-3.1".

For "wx-config" this is a bit more complicated since it is a link to

"/usr/lib/wx/config/gtk3-unicode-3.1" or something similar, depending on

the configuration it was built with. The contents of also differ depending

on the configuration with which it was build.

The Arch Linux packages currently offer either a GTK2 or GTK3

configuration, installing as most things as possible (at least as I

understand it).

Here's the PKGBUILD script:

https://github.com/archlinux/svntogit-packages/blob/packages/wxgtk/trunk/PKGBUILD

It links "wx-config" with the GTK2 "wx-config". This may actually be just

Linux specific dilemma as on Windows and MacOS you would just have one

"wxmsw" or "wxmac" flavor respectively and "wx-config" would links to one

flavor. On Linux, on the other hand you have two GTK flavors. The person

who wrote the script probably choose to link to GTK2 since it was more

widely used at the time, and created a "wx-config-gtk3" link for a GTK3

configuration, but perhaps nowadays the reverse would be more appropiate.

TL;DR I would install the executable links as:

- /usr/lib/wx/config/gtk3-unicode-3.1 -> /usr/bin/wx-config-3.1

- /usr/lib/wx/config/gtk2-unicode-3.1 -> /usr/bin/wx-config-gtk2-3.1

- /usr/bin/wxrc-3.1 -> /usr/bin/wxrc-3.1 (left as is)

I would not install "/usr/bin/wxrc" (link to "/usr/bin/wxrc-3.1") as it

would replace the already installed link to the 3.0.5 version of "wxrc",

since the goal is to be able to install 3.1 alongside 3.0.

By the way these are not changes that must be made to wxWidgets, just the

Arch Linux specific install script.

Later when 3.1.x superseeds 3.0.5 as the "true stable" branch it is

possible to tell package managers that

- /usr/bin/wx-config-3.1 should become /usr/bin/wx-config

- /usr/bin/wx-config-gtk2-3.1 should become /usr/bin/wx-config-gtk2

- /usr/bin/wxrc-3.1 should become /usr/bin/wxrc

Other issues:

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

- /usr/local/share/aclocal/wxwin.m4

- /usr/local/share/bakefile/presets/wx.bkl

- /usr/local/share/bakefile/presets/wx_win32.bkl

- /usr/local/share/bakefile/presets/wx_xrc.bkl

I'm not really sure what these files are for. I think the bkl files are

like bakefile templates to build applications and you mentioned that we

can just stop installing them. Is the same true for "wxwin.m4"? Is it of

any use for application development? If not maybe we can just not install

it, but it's not a decision I can make in upstream. In the test package

that I created I didn't install any of them (any of the 4) and I was able

to compile my application and the internat sample just fine.

Anyways, you mentioned that you didn't like changing changing the name of

"wx-config" and "wxrc". I'll try to make it clear how they will end up

(sorry if I'm repeating myself too much).

In an Arch Linux system with both the currently available 3.0.5 package

and the new 3.1.4 package installed the binaries would look like this.

- /usr/bin/wx-config (3.0)

- /usr/bin/wx-config-3.1

- /usr/bin/wx-config-gtk2 (3.0)

- /usr/bin/wx-config-gtk2-3.1

- /usr/bin/wxrc (3.0)

- /usr/bin/wxrc-3.1

So it's not that we're renaming everything by adding the prefix, we're

just trying to not to stomp on the already installed files. "wx-config"

and "wxrc" will still exist named as is, but they will refer to the 3.0

versions.

Either way, if a developer builds and installs wxWidgets from source

everything is installed under "/usr/local" which hides the executables

from "/usr".

So when you run "wx-config" without having installed from source

$ wx-config --version

3.0.5

and if you then install from source "/usr/local/bin/wx-config" hides

"/usr/bin/wx-config" giving

$ wx-config --version

3.1.4

The "wx-config" installed from package is still the 3.0.5 but the one

installed from source in "/usr/local" is the version of the source you

installed. So someone who installed from package and wants to use 3.1

must call "wx-config-3.1" but if you installed from source you can access

"wx-config" directly, and it will be 3.1.

Lastly, a recap of upsteam changes I'm proposing:

- Fix the locale implementation to read and install with release suffix

- Remove "wxwin.m4" and the presets bakefiles from the Makefile

  installation recipe

Sorry for the long reply and thank you for your time.

[Vadim Zeitlin]

On Mon, 1 Feb 2021 22:14:31 -0800 (PST) Andriy Byelikov wrote:

AB> Okay, after tinkering around for a while here's the follow-up.
AB>
AB> Locale .mo files suffix issue:
AB> ------------------------------
AB>
AB> I have created a patch for the 3.1.4 release, but I'm not sure if this is
AB> all that needs to be done for programs to detect the .mo filles with the
AB> suffix.

I think the change to wxTranslations::AddStdCatalog() should indeed do it,
but we can't stop looking for wxstd.mo without suffix, as it still won't
have it on other systems. So the simplest (and also the slowest, but I'm
not sure if we really care about this) would be to try both versions, first
the one with the version suffix and then, if it failed, the one without it.

AB> What I did is to try to find all references to the "wxstd" catalog
AB> file and to add the release suffix, but I did not find any references to
AB> "wxmsw.mo" files.

There is just a single such file, for Italian, and it has just one
significant commit 4d931bcca0 (Translate '&Help' to '&' for italian Windows
only, 2005-08-12) adding just a single translation. I think we should just
get rid of it, it seemed like a good idea to allow for platform-specific
translations back then, but the fact that it has never been used again
since 15+ years seems to convincingly show that actually it wasn't.

AB> For the installation of these files, I modified the
AB> "wx.bkl" bakefile adding the release suffix to the catalog files the and
AB> regenerating the "Makefile.in". It made some more changes than what I
AB> expected (replacing "dll" with "lib" in some places)

You need to use the latest bakefile 0.2 version to regenerate these files.
But I can do it myself before merging.

AB> Here's the patch:
AB>
AB> https://pastebin.com/FNK2ZtDq

Thanks! If possible, please create pull requests on GitHub, it's simpler
to discuss/annotate things there rather than on pastebin.

AB> I tried to test these changes by compiling the internat sample with the
AB> new patched package that I built with the 3.1.4 release as the source.
AB> I tried to run internat selecting the French locale and it seems to work.
AB> But that is only representative if it actually uses the "wxstd-3.1.mo"
AB> file. If someone who knows better about how the "wxstd.mo" catalogs are
AB> used could test it it would be great.

Yes, it does load wxstd catalog:

https://github.com/wxWidgets/wxWidgets/blob/v3.1.4/samples/internat/internat.cpp#L263

AB> "wx-config" and "wxrc" issue:
AB> -----------------------------
AB>
AB> For "wx-config" and "wxrc" the simple solution is to add a "-3.1" suffix
AB> to the filenames.
AB>
AB> This is trivial for "wxrc" since it is agnostic of whether the build was
AB> configured with GTK 2 or 3, so it would simply be installed as "wxrc-3.1".
AB>
AB> For "wx-config" this is a bit more complicated since it is a link to
AB> "/usr/lib/wx/config/gtk3-unicode-3.1" or something similar, depending on
AB> the configuration it was built with. The contents of also differ depending
AB> on the configuration with which it was build.
AB>
AB> The Arch Linux packages currently offer either a GTK2 or GTK3
AB> configuration, installing as most things as possible (at least as I
AB> understand it).
AB>
AB> Here's the PKGBUILD script:
AB>
AB> https://github.com/archlinux/svntogit-packages/blob/packages/wxgtk/trunk/PKGBUILD
AB>
AB> It links "wx-config" with the GTK2 "wx-config". This may actually be just
AB> Linux specific dilemma as on Windows and MacOS you would just have one
AB> "wxmsw" or "wxmac" flavor respectively and "wx-config" would links to one
AB> flavor. On Linux, on the other hand you have two GTK flavors. The person
AB> who wrote the script probably choose to link to GTK2 since it was more
AB> widely used at the time, and created a "wx-config-gtk3" link for a GTK3
AB> configuration, but perhaps nowadays the reverse would be more appropiate.

Yes, definitely. And normally the idea is, again, to have just a single
wx-config dispatching to multiple wx versions via its command line options,
i.e. you should be able to install both wxGTK2 and wxGTK3 (and even wxMSW
for cross-compiling) and then use "wx-config --toolkit=gtk2" or whatever to
select the toolkit you want.

The complication is that the last installed version becomes the default
one, which means that there is still a conflict. I don't know if there is a
similar mechanism in Arch, but in Debian, from the purely packaging
perspective, I'd install our "real" wx-config with a version suffix and use
the alternatives mechanism to select what the actual wx-config should point
it. AFAICS what you propose is not very far from this, so it looks good to
me and, anyhow, as you say, it's only something you need to do in Arch and
doesn't really require anything from us, which is even nicer :-)

AB> Other issues:
AB> -------------
AB>
AB> - /usr/local/share/aclocal/wxwin.m4
AB> - /usr/local/share/bakefile/presets/wx.bkl
AB> - /usr/local/share/bakefile/presets/wx_win32.bkl
AB> - /usr/local/share/bakefile/presets/wx_xrc.bkl
AB>
AB> I'm not really sure what these files are for. I think the bkl files are
AB> like bakefile templates to build applications and you mentioned that we
AB> can just stop installing them.

Yes, AFAIK nobody uses them (if anybody here does use them, please let me
know!).

AB> Is the same true for "wxwin.m4"?

No, this one is used by many projects using autoconf for detecting wx, it
definitely must be installed.

AB> Lastly, a recap of upsteam changes I'm proposing:
AB>
AB> - Fix the locale implementation to read and install with release suffix
AB> - Remove "wxwin.m4" and the presets bakefiles from the Makefile
AB> installation recipe

 The locale patch looks almost good, I'll try to check if we can get rid
of msw/it.po completely (but I think we can), so the only thing to change
is to try loading both the versioned and unversioned catalog during the
run-time. We still need some solution for wxwin.m4 however.

Thanks a lot for looking at this and I hope we can make it work in time
for 3.1.5 release!

[Vadim Zeitlin]

On Mon, 1 Feb 2021 22:14:31 -0800 (PST) Andriy Byelikov wrote:

AB> Other issues:
AB> -------------
AB>
AB> - /usr/local/share/aclocal/wxwin.m4
AB> - /usr/local/share/bakefile/presets/wx.bkl
AB> - /usr/local/share/bakefile/presets/wx_win32.bkl
AB> - /usr/local/share/bakefile/presets/wx_xrc.bkl
AB>

AB> I'm not really sure what these files are for. I think the bkl files are
AB> like bakefile templates to build applications and you mentioned that we
AB> can just stop installing them.

Sorry, perhaps I was too hasty with my reply here... After looking at

https://github.com/search?q=presets%2Fwx.bkl&type=Code

(I should have done this before posting, of course, sorry) I see that
they're still referenced in quite a few places. I have no idea if they're
actually _used_ anywhere, but removing these files will at the very least
break and require changes to the various packaging scripts and makefiles
using them, which seems unnecessary, so I think it would be safer to just
install them under /build/bakefiles/wxpresets-$VERSION (and ideally create
a symlink from wxpresets to the appropriate wxpresets-$VERSION) instead, as
this shouldn't be that difficult and would minimize the breakage potential.

Sorry again for the first misleading reply,

[Lauri Nurmi]

Vadim Zeitlin kirjoitti 2.2.2021 klo 14:56:
> On Mon, 1 Feb 2021 22:14:31 -0800 (PST) Andriy Byelikov wrote:
>
> AB> What I did is to try to find all references to the "wxstd" catalog
> AB> file and to add the release suffix, but I did not find any references to
> AB> "wxmsw.mo" files.
>
> There is just a single such file, for Italian, and it has just one
> significant commit 4d931bcca0 (Translate '&Help' to '&' for italian Windows
> only, 2005-08-12) adding just a single translation. I think we should just
> get rid of it, it seemed like a good idea to allow for platform-specific
> translations back then, but the fact that it has never been used again
> since 15+ years seems to convincingly show that actually it wasn't.

Platform-specific translations could actually also be useful for e.g.
wxOSX strings that attempt to match Apple's own translations.

However, now that #17673 has been implemented and merged, using contexts
would no doubt be the simplest and the most correct way to handle all this.

[Vadim Zeitlin]

On Wed, 3 Feb 2021 16:40:47 +0200 Lauri Nurmi wrote:

LN> However, now that #17673 has been implemented and merged, using contexts
LN> would no doubt be the simplest and the most correct way to handle all this.

Yes, I'm working on replacing the platform-specific translation files with
contexts. I hoped to finish it yesterday, but probably won't get it done
before the week-end now.

Regards,

[Andriy Byelikov]

Hi! I've created a GitHub pull request for the gettext catalog suffix

issue so we can discuss code stuff there:

https://github.com/wxWidgets/wxWidgets/pull/2219

I have some questions about this you said.

VZ> I think the change to wxTranslations::AddStdCatalog() should indeed do it,

VZ> but we can't stop looking for wxstd.mo without suffix, as it still won't

VZ> have it on other systems. So the simplest (and also the slowest, but I'm

VZ> not sure if we really care about this) would be to try both versions, first

VZ> the one with the version suffix and then, if it failed, the one without it.

You say the reason why we can't stop looking for wxstd.mo without suffix is

because it still won't have it on other systems. However with the changes

I've made to wx.bkl shouldn't the installation install them with prefix on

all systems? And I don't see applications compiled with the newer versions

using the old prefixless files since they won't be generated. Unless these

files do not depend on installing the newer wxWidgets version I don't get

it. Are they always used by the library or only when the user calls them

in their code?

Also on this note, is it necessary to change the internat sample code to

include the catalog file name with the suffix?

On the packaging issue I think I can make it work. I've been checking the

differences on the following conflicting files and I think we can get away

with using the newer 3.1 versions of them on 3.0.

wx-config: changes are mostly version updates and also handling adv libs

           for compatibility

wxrc: from the source code it likely to be compatible, only adds a 'hint'

      node type and handles cases more rigorously

bakefile/presets: drops dmars, watcom, drops os/2, drops ide project

                  formats, updates versions

aclocal/wxwin.m4: adds optional libs options and updates from

        gtk2 and x11 to gtk3 and base

I will install bakefile/presets and aclocal/wxwin.m4 from the latest

official release source as is. It's 3.1.4 now but I think that when the

dust settles we'll already have 3.1.5. If not I'll just add a patch.

wxrc depends on the wxbase libs I think so we will at least have to

install these 3.1 libraries. I'll just install it without the 3.1 prefix.

Arch Linux is a rolling release distro so if the latest wxrc is backwards

compatible this will do.

For the wx-config link I will either just leave whichever was installed

last or leave other links with some toolkit-version suffix when installing

the respective libs. Users may not install all toolkit/version

configuration packages. It's probably the only solution that doesn't give

me a headache and the current mantainer just choose the GTK3 config.

Otherwise the users should just change this link or use the appropiate

options when calling wx-config.

If nothing else comes up I'll finish polishing up the packaging scripts,

https://github.com/andriybyelikov/archlinux-wxwidgets-packages

install the packages and try to run/compile some programs that use

wxWidgets such as Audacity and ask for comments on the Arch Linux forums.

I'll also keep an eye on the pull request status.

Thank you for you time.

[Vadim Zeitlin]

On Sun, 7 Feb 2021 12:18:51 -0800 (PST) Andriy Byelikov wrote:

AB> Hi! I've created a GitHub pull request for the gettext catalog suffix
AB> issue so we can discuss code stuff there:
AB>
AB> https://github.com/wxWidgets/wxWidgets/pull/2219

Thanks!

AB> You say the reason why we can't stop looking for wxstd.mo without suffix is
AB> because it still won't have it on other systems. However with the changes
AB> I've made to wx.bkl shouldn't the installation install them with prefix on
AB> all systems?

People don't use "make install" under MSW and probably not under Mac
neither. Nor does it make sense to use versioned files when you only
install them for your application, as is the case under these systems.

AB> Also on this note, is it necessary to change the internat sample code to
AB> include the catalog file name with the suffix?

AFAICS the sample should continue to work, but perhaps I'm missing
something here, please let me know how do you think it should be changed?

AB> On the packaging issue I think I can make it work.

Great to hear it!

AB> If nothing else comes up I'll finish polishing up the packaging scripts,
AB>
AB> https://github.com/andriybyelikov/archlinux-wxwidgets-packages
AB>
AB> install the packages and try to run/compile some programs that use
AB> wxWidgets such as Audacity and ask for comments on the Arch Linux forums.

Please let us know how it goes here too.

Thanks and good luck!

[Andriy Byelikov]

VZ> AFAICS the sample should continue to work, but perhaps I'm missing
VZ> something here, please let me know how do you think it should be changed?

I was referring to whether loading "wxstd" in internat.cpp:263 should be

renamed to "wxstd-x.y.z" but I guess if the prefixless files are still there then it

shouldn't be a problem.

[Andriy Byelikov]

Hi! I've run into an issue with the install script. Basically I was trying

to compile the demos and samples outside the build directory (because the

demos and samples inside the build directory link against the libraries

inside the build directory) and I noticed that when configuring to use

shared libraries and using --with-regex=builtin the regex and scintilla

libraries are built as static libs and not copied over to the install

directory with make install.

The files are:

- build_dir_name/lib/libwxregexu-3.1.a

- build_dir_name/lib/libwxscintilla-3.1.a

I need them copied over to wherever they should be when running

make install.

I leave you the configure flags I'm using:

../configure --prefix=/usr --with-opengl --enable-graphics_ctx \

  --enable-mediactrl --with-regex=builtin --disable-precomp-headers \

  --with-libpng=sys --with-libxpm=sys --with-libjpeg=sys --with-libtiff=sys \

  --with-gtk=$@

[Vadim Zeitlin]

On Sun, 21 Feb 2021 07:56:15 -0800 (PST) Andriy Byelikov wrote:

AB> Hi! I've run into an issue with the install script. Basically I was trying
AB> to compile the demos and samples outside the build directory (because the
AB> demos and samples inside the build directory link against the libraries
AB> inside the build directory) and I noticed that when configuring to use
AB> shared libraries and using --with-regex=builtin the regex and scintilla
AB> libraries are built as static libs and not copied over to the install
AB> directory with make install.
AB>
AB> The files are:
AB>
AB> - build_dir_name/lib/libwxregexu-3.1.a
AB> - build_dir_name/lib/libwxscintilla-3.1.a
AB>
AB> I need them copied over to wherever they should be when running
AB> make install.

No, you shouldn't need to copy them. These static libraries are linked
into the wx shared libraries and the applications don't need to be linked
with them. I'm not sure how exactly are you building the demos/samples, but
they shouldn't link with these libraries, so it shouldn't be a problem to
not have them.

Regards,

[Andriy Byelikov]

VZ> No, you shouldn't need to copy them. These static libraries are linked
VZ> into the wx shared libraries and the applications don't need to be linked
VZ> with them. I'm not sure how exactly are you building the demos/samples, but
VZ> they shouldn't link with these libraries, so it shouldn't be a problem to
VZ> not have them.

I don't know if they should or not, but they do. I've renamed libwxregexu-3.1.a to

libwxregexu-3.1.b to see what happens the inside the (build_name)/lib folder and

here's the output:

https://pastebin.com/fNdkEzBr

[Andriy Byelikov]

#__LIB_PNG_p \
# = \
# -lwxpng$(WXDEBUGFLAG)$(WX_LIB_FLAVOUR)-$(WX_RELEASE)$(HOST_SUFFIX)
#__LIB_ZLIB_p = \
# -lwxzlib$(WXDEBUGFLAG)$(WX_LIB_FLAVOUR)-$(WX_RELEASE)$(HOST_SUFFIX)

<----
COND_wxUSE_REGEX_builtin___LIB_REGEX_p = \
-lwxregex$(WXUNICODEFLAG)$(WXDEBUGFLAG)$(WX_LIB_FLAVOUR)-$(WX_RELEASE)$(HOST_SUFFIX)
__LIB_REGEX_p = $(COND_wxUSE_REGEX_builtin___LIB_REGEX_p)

<----
#__LIB_EXPAT_p = \
# -lwxexpat$(WXDEBUGFLAG)$(WX_LIB_FLAVOUR)-$(WX_RELEASE)$(HOST_SUFFIX)

### Targets: ###

By removing the lines marked with <---- from the Makefile I was able to

compile the demo and it worked. It looks like we don't need to link to it to

run the executable but the Makefile was generated with it linking to it.

[Vadim Zeitlin]

On Sun, 21 Feb 2021 18:10:18 +0100 Andriy Byelikov wrote:

AB> VZ> No, you shouldn't need to copy them. These static libraries are
AB> VZ> linked into the wx shared libraries and the applications don't need
AB> VZ> to be linked with them. I'm not sure how exactly are you building
AB> VZ> the demos/samples, but they shouldn't link with these libraries, so
AB> VZ> it shouldn't be a problem to not have them.
AB>
AB> I don't know if they should or not, but they do. I've renamed
AB> libwxregexu-3.1.a to libwxregexu-3.1.b to see what happens the inside
AB> the (build_name)/lib folder and here's the output:
AB>
AB> https://pastebin.com/fNdkEzBr

You seem to be using the in-tree makefiles here. They probably are indeed
still wrong, i.e. there shouldn't be any dependencies, but what is the
actual problem? You can't expect the in-tree makefiles to work out of the
tree anyhow, so, to take a step back, what exactly are you trying to do?

[Andriy Byelikov]

I'm trying to test my wxWidgets package on a clean Arch Linux install

and check if I'm missing any dependencies and also see if everything

works. To that end I'm trying to compile and run the out of tree demos,

samples and installs, and see if they work.

[Vadim Zeitlin]

On Sun, 21 Feb 2021 19:33:18 +0100 Andriy Byelikov wrote:

AB> I'm trying to test my wxWidgets package on a clean Arch Linux install
AB> and check if I'm missing any dependencies and also see if everything
AB> works. To that end I'm trying to compile and run the out of tree demos,
AB> samples and installs, and see if they work.

OK, but the point is that you must use wx-config, i.e. makefile.unx, to
build outside the source tree. Do you have any problems if you do this?

Unlike the configure-generated Makefiles, which only work inside the build
tree, makefile.unx can be used anywhere.

[Andriy Byelikov]

I've tried to use makefile.unx to compile the richtext sample and it didn't

work, but I suspect it's a Makefile issue because putting the -o $@ after

the linker flags fixed it. I've also just succesfully compiled wxmaxima

with the package, using the gtk3 3.1 wx-config, and I've confirmed it by

looking at the binary with ldd that it indeed links to the .so5 libraries and

the wxmaxima about dialog also shows that it was compiled with

wxWidgets 3.1.5. Also I gave up on compiling Audacity because it pulls

a wxWidgets fork with custom changes to compile. From what I've tried

so far: some demos, samples, and wxMaxima, it looks like it works.

[Andriy Byelikov]

I've also posted a RFC for the packages on the Arch forums.

https://bbs.archlinux.org/viewtopic.php?id=263892

[Vadim Zeitlin]

On Mon, 22 Feb 2021 20:38:27 +0100 Andriy Byelikov wrote:

AB> I've tried to use makefile.unx to compile the richtext sample and it didn't
AB> work, but I suspect it's a Makefile issue because putting the -o $@ after
AB> the linker flags fixed it.

Sorry, I don't understand this. The command looks fine to me, could you
please explain what error did you get?

AB> I've also just succesfully compiled wxmaxima with the package, using
AB> the gtk3 3.1 wx-config, and I've confirmed it by looking at the binary
AB> with ldd that it indeed links to the .so5 libraries and the wxmaxima
AB> about dialog also shows that it was compiled with wxWidgets 3.1.5.

Great!

AB> Also I gave up on compiling Audacity because it pulls a wxWidgets fork
AB> with custom changes to compile.

This is really unfortunate. Audacity is a big and important application
and I'd like to help make it work with wx 3.1.x, but I just have no idea
why are things so complicated for them :-(

[Andriy Byelikov]

VZ> Sorry, I don't understand this. The command looks fine to me, could you
VZ> please explain what error did you get?

Never mind, I just noticed I was using the 3.0 wx-config version with the 3.1

sample, so of course I had undefined reference errors.

My bad. It works fine now.