Quoth John Emmas: > Thanks Gavin, I do appreciate that Rome wasn't built in a day and > libraries such as gtkmm are always "works in progress". However, when > it comes to auto-generated sources, other libraries seem to be moving > towards Perl, Python or (occasionally) their own, custom tools. All of > these tend to be usable across a wider range of compilers, which is > highly desirable IMHO.
GTKMM *is* actually using a custom tool -- that's what gmmproc is, and it's included in glibmm, which is a prerequisite for all the *mm libraries. It's just that this custom tool happens to be based around M4, with some bits of sh and Perl thrown in (and even some C code in some cases). > Up until recently I did in fact build all the supporting libraries from > tarballs - but keeping those libraries up-to-date (and in sync!) can > become a monumental task. I'm trying to move towards Git (and similar) > as a way of simplifying that process in the future. Up to date, I'll grant you, but I'm not really sure how using Git would help you keep multiple libraries in sync. In fact it seems more likely that you'd get incompatibilities and bleeding-edge not-actually-working-yet code that way (since they update at different times, and may not all keep the tip clean). Unless you're pulling only from specific release version tags, which is little different from downloading the tarball for that release version. So you'd just be adding a new problem on top of your existing (and unchanged) problem. > By all means, keep M4 for the programmers who want it or like it but > flexibility is important too. Not when it introduces extra complexity for no particular benefit. (And I'm not saying that there is no possible benefit in what you're suggesting at all, just that any such benefit is not clear to me from what you've said so far -- and since you're still using the tools "wrong".) The various *mm projects are little more than code-generation wrappers to begin with -- as such changing the code generator essentially means scrapping the entire thing and starting over. And again, maybe there would be some benefit to this (as others have pointed out, the current methods used to update the source files when the upstream library updates are fairly convoluted and painful at present -- but that's in part precisely because various people have hand-rolled things in various different languages at different times, which is an excellent example of how "flexibility" leads to added complexity). Besides, there *are* versions of sh and M4 and Perl and Python available for Windows, so you *can* build the generated files from the git sources yourself if you wish to do that. It's more work than using the pregenerated files from the tarballs (and you have to use the right tools); so I don't know why you'd want to go to that effort when the tarballs are right there. But the option is open. And again, I'm just "some guy", not a maintainer on any of the *mm projects (although I do have some experience with upgrading one to a newer upstream), so you can take what I say with a grain of salt. But I doubt things are likely to change any time soon, as there's quite a bit of infrastructure built up around the current codegen design. (But, as with anything else open-source: if you build it, they might come.) (And, FWIW, my day job is primarily Windows based. But I just use MinGW or a Linux VM when I want to work on GNU-based things.) _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
