Re: Problem of building gtkmm program with CMake under Windows



On Fri, 2009-03-20 at 23:55 +1100, Dancefire wrote:
> 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.

Yeah, I think you can't use pkg-config to find the correct .lib to link
against on Windows, even when using --msvc-syntax (or what it is called)
since it does not know the actual compiler used.

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

I'm not sure what it does, but if it helps building applications with
gtkmm using CMake, and it is not already available elsewhere, then we
might want to add it to gtkmm itself.

> > > 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 any remaining problem which requires this? I'd rather avoid
doing this if the property sheets work equally well. I don't think we
currently have a header file in gtkmm and co. which is guaranteed to be
included.

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

Armin



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