Re: auto-generated file 'gtkmm/widget.h' (widget.hg)

On 16/09/2013 08:29, Kjell Ahlstedt wrote:

Why can't you use the tarball, and refrain from regenerating the .h and .cc files? That would be easier for both of us. Ok, I understand that you won't do that, I just don't know why.

Thanks again Kjell. I'm not averse to using the tarball. It's just a pity because I'm building the entire gtk stack Including related libraries such as freetype, pixman, pango etc - all built from their git sources. gtkmm is the only one which I can't build that way. It just seems a shame that it can't be fixed.

There are some alternatives for you:

1. Use an older version of gmmproc, glibmm 2.31.0 or older. That's how the tarball for gtkmm 2.24.4 was made.

Presumably, that would then give me problems when building glibmm?

2. Use the newest version of gmmproc, but undo the change mentioned in
You will have to change glibmm/tools/m4/base.m4.

And that would bring back the original errors that I reported when building and widget.h?

3. Insert the necessary #include directives in the .hg files, as has been done in gtkmm 3. You can get some help from the shell script glibmm/tools/test_scripts/ It will find the header files that need more #include directives, but it won't tell you which files to include.

That's a possibility I suppose....

Don't expect a new release of gtkmm 2, compatible with the newest releases of gmmproc, or a new release of gmmproc (glibmm), compatible with existing releases of gtkmm 2.

Maybe I'm missing something here - but if glibmm needs version X of gmmproc while gtkmm needs version Y, wouldn't it be sensible for each library to contain the specific version that it needs? Or to put it another way, why does gtkmm need to use the glibmm version of gmmproc? Why can't it have a self-contained version for its own use?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]