Hi Julius,
Hi Tom,
Very clear. So, lets follow your advice and forget about the CI system we had in mind: we will rely on you :).
I downloaded your installer to start playing with it. Two questions:
instead of the old stable ones that I compiled myself.
1. Do you plan to integrate 32 bit binaries in the installer?
No, I don’t do legacy support. It should not be hard to generate them yourself though since MSYS2 also offers all the 32-bit dlls in the gtkmm2/3 stacks. 2. Do you plan to integrate glade in the installer?
Glade is an executable in its own right, and there is no need to include it in a gtkmm2/3 runtime environment and can be installed via MSYS2 if you want to create user interface XML files. Or are you referring to the libglade-ui library?
Best,
Tom
Hi Julius,
Hi Tom,
I'm a colleague of Romain. Thanks to you, and all others, for the answers.
What came out of our search is that there is no one-click Gtkmm development environment installer on WIndows which is continuously maintained. All efforts have been interrupted at some point in time because the maintainers get exhausted or some of the tools or components they based their work on were discontinued. This is the "nice volunteer suffered a burn out: next one" situation.
Well I like to think that my runtime installer is pretty well maintained :-) And with my transition to MSYS2, I will be able to make even more frequent releases as I won’t have to spend a weekend compiling the gtkmm2 and gtkmm3 stacks :-) The MSYS2 development environment is pretty solid, and has quite a large number of people contributing to it. Also, whenever you think a project is useful but looks like it is not properly supported anymore, consider stepping in and bringing it back to life. This is how open source works and there is absolutely nothing wrong with that.
Ideally, we would like to set up a continuous integration system which would automatically checkout sources from official repositories, build binaries, package them into an installer and make the installer available to the community. Therefore no more "nice volunteer suffered a burn out: next one" situation.
Appveyor is currently the most used CI system for Windows, but compiling the complete gtkmm2/3 stack on them will not work as you will hit the one hour time limit before it’s finished building all packages. You shouldn’t have to build the gtkmm2/3 stack yourself though, as you can use the binary packages offered by MSYS2, which are usually updated quite quickly after they are officially released. In case there is a delay in updating the packages, open a PR yourself at https://github.com/Alexpux/MINGW-packages/pulls
To achieve this without reinventing the wheel, we were interested in being pointed to a good starting point. Your project seems to be the good candidate because it seems to be the most up to date. So up to date that we wonder if our proposal to set up a CI system is still meaningful for the community. Let us know...
Well, with the migration to MSYS2-MINGW64 it should take me 15 minutes or so to make new Gtkmm2/3 runtime installers. If I do that once a month, I think everybody will be satisfied. Keep also in mind that very often packages in the gtkmm2/3 stack need patching before they can be compiled or work properly on Windows… If you would like to create a CI system that builds all these packages from scratch, you will need to spend quite some time gathering the sometimes necessary patches, or writing them yourself… I have been doing this up to now and I can assure you there is no fun in doing so. The packages provided by MSYS2 were compiled from patched source code and should work properly, which often explains why there was a bit of a delay before updates become visible in the package list.
One question: does using MSYS2 to generate the binaries generate a dependency on Cygwin library (dll)? If yes, that does not fit the purpose of having a native Windows environment.
Once again, thanks to you all.
Best regards,
Tom Julius
Hi,
Installing either of these packages will optionally modify the PATH variable so it will get picked up by your software. Alternatively, it can be included in your own software installer, and unpackaged in the same folder as your own dlls and/or executables.
The current stable packages were compiled from source by myself, but due to the big effort involved, and due to the fact that the TDM-GCC compiler I used seems unmaintained at this point, I am currently migrating to new versions of the installers that extract the required files from an MSYS2-MINGW64 installation. More information about this migration at https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer/pull/6
Best,
Tom
On 26/12/2016 08:02, Romain CENDRE wrote:
the company for which I'm working for, is interested in making build of GTKMM for Windows and I think that's not an easy part. And I'm asking you for all informations that can help us to do this job and support this lib for Windows platform.
As someone who regularly builds gtkmm on Windows I initially found this message a bit confusing. Admittedly, though... I'm still building gtkmm version 2. But when I typed "gtkmm" and "windows" into Google, I soon realised that a lot of the links seem to end up in a page which says "this page has not been created yet". Binary packages (i.e. pre-built libraries) do exist though:- http://www.gtkmm.org/en/download.shtml#Binary So maybe there's been some delay in creating the various information pages?? Anyway Romain - you'll need to consider which compiler you want to use. MSVC and mingw (gcc) are both supported. Maybe someone will correct me here - but from a look at my own installation, VC5, VC8 and VC10 are the only MSVC compilers supported currently (for gtkmm v2). And (I'm guessing here...) the pre-built binary packages are most likely built with gcc. They're probably okay to get you started - but if you're building your app with (say) MSVC10, you should ultimately aim to build your GTK libs with the same compiler. Remember also that you'll need libraries which match your app (64-bit libs for a 64-bit app or 32-bit libs for a 32-bit app). And don't forget that libgtkmm isn't a stand-alone library. It needs other dependencies, such as libglib / libgtk / libsigc++ etc, etc. A guy called Tarnyko is probably one of the most prolific supporters of GTK/GTKMM for Windows. Search in Google for "tarnyko" and "gtk". John _______________________________________________ gtkmm-list mailing list gtkmm-list gnome orghttps://mail.gnome.org/mailman/listinfo/gtkmm-list
|