Re: comments on the gtkmm -vcXX- naming convention
- From: Armin Burgmeier <armin arbur net>
- To: Philip Kovacs <phil kovacs gmail com>
- Cc: gtkmm-list gnome org
- Subject: Re: comments on the gtkmm -vcXX- naming convention
- Date: Wed, 15 Oct 2008 21:35:58 +0200
On Wed, 2008-10-15 at 15:04 -0400, Philip Kovacs wrote:
> * Armin Burgmeier <armin arbur net> [2008-10-15 20:25:22 +0200]:
>
> > On Wed, 2008-10-15 at 13:33 -0400, Philip Kovacs wrote:
> > > I installed the latest gtkmm Windows development package and I
> have
> > > some comments.
> > >
> > > From the point of view of application developers who require gtkmm
> as
> > > a dependency, this new -vcXX- naming convention for the import
> libraries
> > > is a burden.
> > >
> > > I have to rework my build systems to handle this new library
> naming
> > > convention; offer end-users a switch to select VC80/90 and then
> link
> > > to the correct libraries after "assembling" a library name based
> on the
> > > switch.
> >
> > I don't know what your end-users are (actual users, or application
> > developers?), but can't you just use the vc80 binaries if you are
> > building with MSVC++ 2005 and the vc90 ones if you are building with
> > MSVC++ 2008?
>
> I am the developer, so my end-users are the ones who will install
> the
> gtkmm runtime in order to use my applications.
I still don't get what the problem is with this. You decide what you
build your application with, and things will just work for the users
because the runtime package contains all the necessary files to run the
application, regardless whether you build against the MSVCRT80 or the
MSVCRT90 runtime.
> The argument that "confusion would result" if people copied the gtkmm
> files into Windows/System32 is specious. People simply should not
> be doing that. You should install gtkmm to a non-system directory
> and
> then use the path environment var to add the gtkmm bin/ to your path.
But if there are two applications, one built with MSVC 2005 and one with
MSVC 2008, then they should use different DLLs, right? If these DLLs
have the same name, then this cannot work (at least not if the DLLs are
meant to be shared).
> My issue with the naming convention is that developers, such as
> myself,
> now have to make some very unusual changes to their build systems
> to link gtkmm/glibmm/cairomm/sigc correctly.
Sorry, I don't get it. What changes do you have to make, and why? Is the
problem that you rather want to change the library search path instead
of the library names to toggle between the vc80 and the vc90 builds?
> Furthermore, there is no real need to tag the import libraries with
> the
> runtime name since the link libraries can easily be observed with
> programs
> like depends.exe. Anyone who is "confused" as to what gtkmm-2_4.dll
> links
> to can use depends, or programs like it, to observe what is going on.
But we still couldn't have both shared vc80 and vc90 DLLs if they would
have the same name. The import libraries have been tagged with the same
convention because linking against a vc80 import library makes the
program depending on the vc80 DLL, and linking against a vc90 import
library makes the program depending on the vc90 DLL.
> The visual cue in the filenames is very unusual and throws a problem
> back
> to all build systems that have the *mm's as deps.
We used the same conventions as the boost C++ libraries, here:
http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#library-naming
So this seems not to be too unusual. Would you have the same problems
with boost?
> Even if you were to maintain only one installer, it would be better to
> install
> several trees that are rooted by the runtime version, rather than
> create one
> tree and use these names.
>
> I hope you will consider it.
First, I would be interested in a few more opinions on this.
> Phil
>
> BTW I know you worked hard on the new installer and my criticism is
> meant
> to be taken in a constructive light.
Armin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]