Re: using GLIBMM_PROPERTIES_ENABLED & co



On Mon, 2008-04-28 at 13:16 +0300, Ionutz Borcoman wrote:
> Hi,
> 
> >From what I have seen, gtkmm allows a couple of flags to be set during 
> configure time:
> 
>     * --enable-deprecated=no
>     * --enable-api-exceptions=no
>     * --enable-api-properties=no
>     * --enable-api-vfuncs=no
>     * --enable-api-default-signal-handlers=no
>     * --enable-api-atk=no
> 
> >From what I understand, by using these defines you change what is included in 
> the final libs and defines some variables (for example,  I guess that using 
> the --enable-api-exceptions controls the GLIBMM_PROPERTIES_ENABLED).
> 
> This is all nice for the lib, but it is a pain in the a** for the developer. 
> What am I suppose to do? Litter all my code with #ifdef XXX #else #endif?

Only if you care about your application running on Maemo, or on some
similar custom embedded environment. Very few applications bother to do
this and it does them no harm.

> I would have understood and found it nice if this was controlled by some 
> define I can put before including the gtkmm.h or other similar header. But 
> from what I understand this controls the lib itself. Am I right?

Yes, in order to reduce code size.

> Can I define myself these variables to change the behavior of gtkmm? How are 
> the users (developers) of gtkmm cope with this if it is determined at compile 
> time? If some Linux distro decides to use a different set of compile-time 
> flags,

No distro does this. And any non-embedded distro that did it on purpose
would be a rather stupid distro that we could feel free to ignore.

>  then a gtkmm developer must do a lot of coding just to support all the 
> possible flag combinations. This looks quite a stopper for using gtkmm.

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com



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