Library naming with GCC on MSW

[PB]

Hi,

It seems that there are two naming schemes for static/import libraries built with GCC on MS Windows. One is used for files built with the bundled GCC makefile (same as for MSVC), the other when building with GCC makefile generated with bundled CMake file (matches configure one?). For example, for the base library it is libwxbase31ud.a vs libwx_baseud-3.1.dll.a.

This means that the file names produced using CMake are not only different from those used by the official binaries but AFAICT they are also incompatible with CMake’s module FindwxWidgets used via find_package(), doing which is recommended by wxWidgets documentation and demonstrated in the minimal sample.

FWIW, it appears that this naming scheme is also incompatible with 3rd party tools such as Code::Blocks wxWidgets project wizard or wx-config Windows executable used by CodeLite.

I am not asking for it to be changed, I am just curious about why this choice was made and wanted to ask before 3.2 is released and this is set in stone forever.

Thanks,
PB

[Maarten Bent]

Hi,

The last time I updated the CMake library names it was focused on making them compatible with the Visual Studio solutions (MSVC) and configure (gcc/clang).
I think makefile.gcc uses the same naming convention as MSVC. So this is indeed not fully covered by CMake.

I could add an option to choose the naming scheme when using gcc/clang on Windows. For compatibility with the use cases you mention, it should use the MSVC naming convention as default. I suppose for configure it also matters less what convention is used since the generated wx-config will know the names.
Or maybe it can use same check as FindwxWidgets uses (WIN32 AND NOT CYGWIN AND NOT MSYS ..) to determine what convention to use.

In https://github.com/wxWidgets/wxWidgets/pull/2358 I'm updating the library naming conventions document with all the changes that happened over the last 20 years. I also intend to update CMake in case it deviates from it (I haven't checked it thoroughly yet). I can include a fix/proposal for this issue as well.

Maarten

--
To unsubscribe, send email to wx-dev+un...@googlegroups.com
or visit http://groups.google.com/group/wx-dev

---
You received this message because you are subscribed to the Google Groups "wx-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-dev/b43f1a3b-f419-4a0d-ad61-0cfb354b9c0fn%40googlegroups.com.

[PB]

Hi Maarten,

thanks for the quick reply (and all the work on CMake files).

On Saturday, May 22, 2021 at 12:17:31 AM UTC+2 maart...@gmail.com wrote:

I could add an option to choose the naming scheme when using gcc/clang on Windows. For compatibility with the use cases you mention, it should use the MSVC naming convention as default. I suppose for configure it also matters less what convention is used since the generated wx-config will know the names.
Or maybe it can use same check as FindwxWidgets uses (WIN32 AND NOT CYGWIN AND NOT MSYS ..) to determine what convention to use.

I do agree with this option, I did not dare to propose it in my first post. IMO, it makes most sense and satisfies both "traditional" and configure camps.

I would personally prefer an advanced CMake variable for library naming scheme with three options: (1) default (uses the same check as FindwxWidgets above), (2) mingw makefile, and (3) configure. But perhaps this is too complicated and just having a hard-coded check would suffice in practice.

  On Saturday, May 22, 2021 at 12:17:31 AM UTC+2 maart...@gmail.com wrote:

In https://github.com/wxWidgets/wxWidgets/pull/2358 I'm updating the library naming conventions document with all the changes that happened over the last 20 years. I also intend to update CMake in case it deviates from it (I haven't checked it thoroughly yet). I can include a fix/proposal for this issue as well.

I am aware of it, having nagged there some time ago. ;)

 

I understand that since I am MSW-only I may seem biased and someone looking at this with configure-colored glasses may consider all this a non-issue. Nevertheless, I believe that maintaining backward compatibility with CMake and other tools is important, even more so when the bakefile-based system may be in the future phased out and replaced by the CMake one entirely.

Regards,

PB

[Vadim Zeitlin]

On Sat, 22 May 2021 00:17:27 +0200 Maarten Bent wrote:

MB> The last time I updated the CMake library names it was focused on making
MB> them compatible with the Visual Studio solutions (MSVC) and configure
MB> (gcc/clang).

IMO these are the 2 most important use cases, so whatever else we (well,
you) do, CMake library names should remain compatible with them.

MB> I think makefile.gcc uses the same naming convention as MSVC.

Yes, I think all the makefiles (of which only 2 remain now, but used to
have 4 relatively recently and even more in the past) used the same
convention.

MB> I could add an option to choose the naming scheme when using gcc/clang
MB> on Windows. For compatibility with the use cases you mention, it should
MB> use the MSVC naming convention as default. I suppose for configure it
MB> also matters less what convention is used since the generated wx-config
MB> will know the names.
MB> Or maybe it can use same check as FindwxWidgets uses (WIN32 AND NOT
MB> CYGWIN AND NOT MSYS ..) to determine what convention to use.

From what (little) I know about CMake, it seems relatively common to try
all the possibilities in it, so I think doing this could be the best fit
for the people expectations, as they just want their project to build...

In any case, thanks again for looking into all this!
VZ