Re: Problem of building gtkmm program with CMake under Windows

[Dancefire <dancefire gmail com>]

On Fri, Mar 20, 2009 at 9:54 PM, Armin Burgmeier <armin arbur net> wrote:
>
> On Fri, 2009-03-20 at 17:41 +1100, Dancefire wrote:
> > Hi,
> >
> > Has anyone successfully build gtkmm program with CMake under Windows?
> > I have tried, but got many problem, one is inside the cmake script of
> > finding gtkmm. The problem is that it use pkg-config for finding
> > gtkmm. It's ok to find the location of the library, however, it's fail
> > to get the correct library name. The script trying to link my simple
> > gtkmm program with "gtkmm-2.4.lib":
>
> I don't know CMake at all. Where does the "gtkmm-2.4.lib", which does
> not exist, come from?
>

For other library, such boost, there is module in CMake to find such
library, such as FindBoost.cmake. However, there is no module to find
gtkmm in the standard CMake distribution. There is an alternative way
to find gtkmm, which is using module FindPkgConfig.cmake, which is
actually calling pkg-config to find the gtkmm's location and includes,
libs. So, gtkmm-2.4.lib is come from pkg-config. Which is actually
provided for MinGW.

I currently used a module found in CMake maillist, FindGTK2.cmake, to
do the job. Now looks alright.

> > LINK : fatal error LNK1104: cannot open file 'gtkmm-2.4.lib'
> >
> > however, there is only:
> >
> > gtkmm-vc80-2_4.lib
> > gtkmm-vc80-d-2_4.lib
> > gtkmm-vc90-2_4.lib
> > gtkmm-vc90-d-2_4.lib
> >
> > Is there anything we can do to make my gtkmm program build with CMake
> > automatically?
>
> > The name format of .lib file is similar to the Boost library. In
> > Boost, it use autolink technology to handle the link problem under
> > different compile setting. Can gtkmm use autolink to replace the
> > settings in MSVC property sheet? I think it is better way for MSVC.
>
> If I understand this correctly, then auto-linking would basically
> require some #pragma lib(gtkmm-vc80-2_4.lib) lines in a header file.
> However, how does that header file know what version of the library to
> link with?
>

Boost use the pre-defined value by compiler do the job.

MSVC will define _MSC_VER, which contain the version of current compiler.

_MSC_VER:
< 1300 : vc6
1300: vc7
1310: vc71
1400: vc80
1500: vc90

Boost autolink header will check _MSC_VER and then define
BOOST_LIB_TOOLSET to vc80 or others.

And finally use #pragma comment(lib, xxx) to use the library,

#  pragma comment(lib, BOOST_LIB_PREFIX
BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET
BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT "-" BOOST_LIB_VERSION ".lib")
#  ifdef BOOST_LIB_DIAGNOSTIC
#     pragma message ("Linking to lib file: " BOOST_LIB_PREFIX
BOOST_STRINGIZE(BOOST_LIB_NAME) "-" BOOST_LIB_TOOLSET
BOOST_LIB_THREAD_OPT BOOST_LIB_RT_OPT "-" BOOST_LIB_VERSION ".lib")
#  endif



> A way I could think of would be to add a "gtkmm_link.h" file or
> something into special subdirectories, one for each version of the
> library we provide, such as gtkmm-vc80-2_4. Then, the property sheet
> could add the path corresponding to its version to the include search
> path.
>

The library name will only be finalized when user try to compile the
code, so at that moment, the version of the library is determinated.
Just like BOOST_LIB_VERSION, set the value before include the generic
auto link header file, then auto link is done.

> Finally, we would need to make sure that "gtkmm_link.h" is included
> whenever including a gtkmm header file. So we'd basically need to add it
> to every gtkmm header. Plus every libxml++ and libglademm header. I'm
> not sure we want this.
>

Yes, at least for each library, there should be a header which include
the auto_link.h. Sometimes, there are common header file in library,
such as gtkmm/base.h, which can be used to include the auto_link.h,
which same some work. I will have a try later to see how much work
need to be done.

> Is there a better approach to do the auto-linking?
>
> Armin
>
>

--
Tao Wang