Stop using bakefile 0.x (Issue #23249)
VZ
Unfortunately this thread didn't really result in any confusion, but we still need to stop depending on unmaintained and obsolete bakefile.
Things currently preventing us from doing it:
-
Makefile.infor building the library itself under Unix. In the worst case, we can maintain this one manually. Maybe we could try to use automake to facilitate this, but I'm not sure how well does it work without libtool and I am almost sure that we don't want to use libtool. - Samples (and utils, tests etc) makefiles. There are too many of them to maintain them by hand, so we need some tool to help us. Premake could be a good choice, but it would be really great to have some help from somebody already familiar with it. Xmake is another possibility. Finally, if all else fails, we can write our own ad hoc tool, but I'd rather avoid this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I've done one thing to facilitate migrating from bakefile: in #24937 I've added MSVS project files for all the samples (and we already had them for the tests). This leaves demos and utils, but
- I wonder if demos shouldn't be just dropped, they're completely unmaintained and really don't look as impressive in 2024 as they did in 1994.
- Among utils, only wxrc is really useful and I think we could add a manually created project file for it too, it doesn't change very often.
If/when we do this, we could remove all makefile.vc files. This still leaves makefile.unx and makefile.gcc, which I'm also tempted to just drop, and Makefile.in ones — which we definitely need to preserve and find some way to deal with updating them. Unfortunately I still don't see any good way forward here, my attempts to use Premake have failed...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Eran Ifrah
We already have good CMake (this is how I build wxWidgets on Windows) - why add another tool like Premake or Xmake (?)
BTW, (never used it) but CMake can generate MSVC projects as well
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I don't want to force people to install CMake and as long as we have another build system (configure-based) anyhow, it should be possible to build the samples etc using it too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Eran Ifrah
I am guessing that I will need to install premake? or xmake?
Beside, these days, CMake is available on platforms that wxWidgets is supported
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Both these tools can generate make/project files usable without them (just as bakefile did). But we're very far from using either of them anyhow.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23249)Unfortunately this is not going to happen before 3.3.0, we're still stuck with bakefile for the time being.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Brickmasterhunt
Brickmaster1 left a comment (wxWidgets/wxWidgets#23249)I would be forever grateful if this library adopted XMake!!! It is the first build tool I have used that I actually liked, and it needs a big project like this to use it and popularize it, it's also very well compatible with cross-compiling and native UI's are one of the most difficult things to find done well, wxWidgets is really the only library that does it well, and is versatile.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23249)It would be great if somebody could contribute at least a skeleton XMake-based system that would be capable of generating XCode projects.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Brickmasterhunt
Brickmaster1 left a comment (wxWidgets/wxWidgets#23249)It would be great if somebody could contribute at least a skeleton XMake-based system that would be capable of generating XCode projects.
Oh did you try and not have success with XCode??
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Brickmasterhunt
Brickmaster1 left a comment (wxWidgets/wxWidgets#23249)Personally I am really working to try and get the current CMake-based xmake package for wxWidgets to build under the Zig cross compiling toolchain for C++. It is a tall task and I have not yet been successful, but if I can get it to work it means you only need one machine, and you can build every version of the package/library.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Brickmasterhunt
Brickmaster1 left a comment (wxWidgets/wxWidgets#23249)XMake is mostly platform agnostic.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Brickmasterhunt
Brickmaster1 left a comment (wxWidgets/wxWidgets#23249)It would be great if somebody could contribute at least a skeleton XMake-based system that would be capable of generating XCode projects.
Just realized about the previous comment, I suppose you wouldn't know since there were never any basic xmake attempts made, but xmake supports XCode as a toolchain, you would need xmake to initially make commits to the project related to build system matters, but it supports generating XCode project files behind the scenes through first making cmakelists and then having cmake generate XCode project. It can also generate makefiles, cmakelists, and build.ninja, and many more. It is as expansive as you want it to be, but in my experience using the xmake tools itself is the easiest and smoothest way to get things done with the most support. There is nothing saying you couldn't just provide generated versions of these files with each important commit, it will just increase the build time some, so maybe be conservative and have it be a toggle during build by default. XMake also makes including libraries much more flexible, and makes it much more viable if you wanted to, for example, build X11 or Wayland on windows to then compile the program for Linux. MacOS is kinda tough because you will need a sysroot for the frameworks, but possible if you have a way of obtaining one (I know there are a couple ways floating around on github).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23249)To be clear, what I'm really interested in is a bakefile-like generator for the "native" project files for MSVS and XCode. We already can build using these toolchains with CMake, but it's not that great to work with CMake-generated projects, so something generating more "human-like" projects would be a plus.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Thomas Krebs
They could be much better than today.
We edit them to our convenience for every release.
Am 02.04.2025 um 07:27 schrieb VZ:
> To be clear, what I'm really interested in is a bakefile-like generator
> for the "native" project files for MSVS and XCode. We already can build
> using these toolchains with CMake, but it's not that great to work with
> CMake-generated projects, so something generating more "human-like"
> projects would be a plus.
>
> —
> wxWidgets/wxWidgets/issues/23249#issuecomment-2772403452>, or
> unsubscribe <https://github.com/notifications/unsubscribe-auth/
> AXD7XGDV5S2JDFPAE7XDHGT2XPJRRAVCNFSM6AAAAABRDCDHWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZSGQYDGNBVGI>.
> You are receiving this because you are subscribed to this thread.Message
> ID: <wxWidgets/wxWidgets/issues/23249/27724...@github.com>
>
> vadz*vadz* left a comment (wxWidgets/wxWidgets#23249) <https://
> github.com/wxWidgets/wxWidgets/issues/23249#issuecomment-2772403452>
> To be clear, what I'm really interested in is a bakefile-like generator
> for the "native" project files for MSVS and XCode. We already can build
> using these toolchains with CMake, but it's not that great to work with
> CMake-generated projects, so something generating more "human-like"
> projects would be a plus.
>
> —
> wxWidgets/wxWidgets/issues/23249#issuecomment-2772403452>, or
> unsubscribe <https://github.com/notifications/unsubscribe-auth/
> AXD7XGDV5S2JDFPAE7XDHGT2XPJRRAVCNFSM6AAAAABRDCDHWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZSGQYDGNBVGI>.
> You are receiving this because you are subscribed to this thread.Message
> ID: <wxWidgets/wxWidgets/issues/23249/27724...@github.com>
>
> --
> 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 <mailto:wx-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/wx-dev/
> wxWidgets/wxWidgets/issues/23249/2772403452%40github.com <https://
> groups.google.com/d/msgid/wx-dev/wxWidgets/wxWidgets/
> issues/23249/2772403452%40github.com?utm_medium=email&utm_source=footer>.
Vadim Zeitlin
TK> What would be the problem editing the project files manually?
Well, doing it manually... It's a pain, especially for the Xcode projects.
TK> They could be much better than today.
TK> We edit them to our convenience for every release.
I wonder what do you change?
VZ
Thomas Krebs
As our app uses other libraries, that use some open source
libraries as well I do not like to include these twice, I
remove the expat, png, jpeg, tiff and zlib libraries from
wx and use their original versions, with sometimes newer releases
than used in wx.
As we use mostly dlls I found that all projects in wx link to these
libraries, although this would not be necessary. The linking of the wx
base would suffice for linking with the zlib, while the other wx
libraries don't need to link with zlib.
As the path to the original open source libraries is different I need to
change the link path or delete the unnessecary link dependencies in all
other wx library projects.
That is the most work I have to do. This is not a big problem, but as I
say, these link dependencies are not necessary.
There are other things that might be changed to make the project
settings simpler and for my understanding better:
- There is no need to use the settings in wx_config.props for the
PlatformToolst. You can set it to $(DefaultPlatformToolset), then
you can remove wx_config.props.
- There is also no need to have different version of the
wx_<vc-version>.sln file. One wx.sln would be ok for all versions > VC9.
- The naming convention of the $Configuration is sadly different
than the standard naming convention of Microsoft.
They use a "Release DLL" and "Debug DLL" scheme rather than
"DLL Release" and "DLL Debug" in wx. That stops using the standard
"$(Configuration)" variable in all depending projects.
- The use of a release number in the name of the wx linking libraries is
not needed.
As all the libraries are in a path of a wx release, such a disciminating
naming is superfluous. Microsoft uses the name msvc(p)(d).lib since
decades without any problems. This would make a switch between wx
releases for- and backwards much easier.
This is more or less what I can contribute to this discussion.
TK
Vadim Zeitlin
TK> As our app uses other libraries, that use some open source
TK> libraries as well I do not like to include these twice, I
TK> remove the expat, png, jpeg, tiff and zlib libraries from
TK> wx and use their original versions, with sometimes newer releases
TK> than used in wx.
We can't do this in our own projects and unfortunately I don't see how
could we restructure them to make this easier to do. But please let me
know if you do!
TK> As the path to the original open source libraries is different I need to
TK> change the link path or delete the unnessecary link dependencies in all
TK> other wx library projects.
TK> That is the most work I have to do. This is not a big problem, but as I
TK> say, these link dependencies are not necessary.
I'm not sure what exactly is necessary and what isn't, but if you have a
patch that could be applied without any ill effects by default and make
life easier for you, please create a PR with it.
TK> There are other things that might be changed to make the project
TK> settings simpler and for my understanding better:
TK> - There is no need to use the settings in wx_config.props for the
TK> PlatformToolst. You can set it to $(DefaultPlatformToolset), then
TK> you can remove wx_config.props.
TK>
TK> - There is also no need to have different version of the
TK> wx_<vc-version>.sln file. One wx.sln would be ok for all versions > VC9.
Those are related and I disagree in both cases: we want to have different
SLN files and we want to set PlatformToolset differently depending on the
SLN file used because we want to allow building with different MSVS
versions if you have more than one installed. This may be a niche use case,
but it doesn't cost that much to support it and it's pretty useful when you
do need it.
TK> - The naming convention of the $Configuration is sadly different
TK> than the standard naming convention of Microsoft.
TK> They use a "Release DLL" and "Debug DLL" scheme rather than
TK> "DLL Release" and "DLL Debug" in wx. That stops using the standard
TK> "$(Configuration)" variable in all depending projects.
We could change this. Again, if you already have a patch, please consider
creating a PR doing this, otherwise please open an issue to remind me to do
it before 3.3.0.
TK> - The use of a release number in the name of the wx linking libraries is
TK> not needed.
We intentionally use it to prevent you from linking with an incompatible
library accidentally and I don't think it's a good idea to change this,
doing this can result in a lot of grief and it's much better to get link
errors than run-time ones.
TK> As all the libraries are in a path of a wx release, such a disciminating
TK> naming is superfluous. Microsoft uses the name msvc(p)(d).lib since
TK> decades without any problems.
They also preserve ABI compatibility since decades. We don't.
TK> This would make a switch between wx releases for- and backwards much
TK> easier.
If you use wxwidgets.props (as strongly recommended) you shouldn't have
any need to hardcode wx libraries names, let alone their versions, in your
projects.
TK> This is more or less what I can contribute to this discussion.
Thanks for your feedback, it's appreciate, even if I don't agree with all
the proposed changes.
VZ
Avery King
generic-pers0n left a comment (wxWidgets/wxWidgets#23249)I'd like to throw in my 2 cents here. Before that, I must make a disclaimer that I'm not familiar with the two, but if needed, I'm up for learning more about them. Maybe I can figure out how to make a new Premake or Xmake build system for wxWidgets if desired, but we'll see.
From what I understand, it appears that Premake might be the most suitable option based on what I've read from this issue and others. It seems like the goal is to keep a build system that generates usable build files where users can use their favorite build tool (make, Xcode, Visual Studio, etc.) without having to have Premake installed or anything. In a way, this is similar to CMake except the actual generated files are usable (as, from my understanding, CMake-generated projects are not meant to be used outside the build process).
Xmake, on the other hand, looks pretty neat! However, I understand it to be yet another actual build system rather than just a meta-buildsystem, although "it can generate project files like CMake or Meson" (according to it's introduction). Knowing how CMake-generated build files aren't supposed to be used outside the build process, this sounds like those build files would also end up the same way.
TL;DR: I think Premake would be the most suitable option for replacing bakefiles.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23249)I also thought Premake would be the best solution, but after trying to use it for the samples, I realized that a lot of work would be needed to reproduce what we have currently. I don't remember all the details any more, but I think there was a problem with being able to use either static or dynamic wx libraries and factoring out setting common to all samples was also not that easy to do. So while I still think that it should be possible to use Premake for us, it seems very unlikely that I ever find enough time to do it myself, i.e. it would need to be done by somebody else or not done at all.
Xmake looked promising but I don't know if we can really commit to it. And, of course, somebody still needs to write all xmake.lua files...
To be honest, the most likely scenario seems to be that we just abandon all generated build files, i.e. we'll have only
- CMake
- MSVS project files
Makefile.inused withconfigure
This is not ideal but I don't see us releasing 3.4 still using bakefile 0.x and I don't see any other realistic solutions :-(
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Avery King
>
>
> 2. MSVS project files
>
> 3. `Makefile.in` used with `configure`
>
> This is not ideal but I don't see us releasing 3.4 still using bakefile 0.x and I don't see any other realistic solutions :-(
Randalph
- Visual Studio 2017 (version 15) and later supports opening the wxWidgets folder which contains a CMakeLists.txt file and it will use CMake to build (which comes with the VS installation) instead of *.vcxproj
- I have not tested it beyond getting it to work for wxlunasvg, but I do have a clone of bakefile that I updated to use python 3.11.9 so that it isn't necessary to hunt down and install an ancient python system...
--
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 visit https://groups.google.com/d/msgid/wx-dev/wxWidgets/wxWidgets/issues/23249/3481556931%40github.com.
Brickmasterhunt
Brickmaster1 left a comment (wxWidgets/wxWidgets#23249)To be completely honest, I like CMake out of these options too, because I use XMake as my main build system and it is extremely simple to include CMake built packages/projects in your project (ex. wxWidgets's cmake now). For my specific use case, being able to use cross compiler with it and have the package be one unified thing I can cross compile with is really nice, I don't have to deal with the MSVS or XCode crap, I can just build the exact same deterministic way on every platform, to any platform.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Avery King
generic-pers0n left a comment (wxWidgets/wxWidgets#23249)For my specific use case, being able to use cross compiler with it and have the package be one unified thing I can cross compile with is really nice, I don't have to deal with the MSVS or XCode crap, I can just build the exact same deterministic way on every platform, to any platform.
I think this also highlights another good point about CMake: you don't have to deal with what otherwise is, as I argue, an entirely different build system. Sure, the projects may be simple enough, but I argue that it would be even simpler to deal with just a single build system that works across all platforms.
On another note, I do find Xmake pretty interesting, and I'll probably experiment with it myself! Anyways, I've digressed 😄
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.