qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Rolke <cro...@redhat.com>
Subject Re: Version and icon resources for Qpid cpp executables on Windows
Date Tue, 29 Jun 2010 13:08:53 GMT
I agree with Andrew for his stated reasons. After thinking about it a little more how about
this maybe a hybrid mix of #1 and #2 would work:

1. For each exe/dll, add a .rc file that puts some default version number and an Apache Qpid
icon. The icon is an elegant "Q" with the Apache feather for the hook of the Q.

2. The post-build version patch would involve changing only the version text string resource.

For folks who don't care about the version, they will get something that's not unreasonable.
For folks who do care about the version, the process of patching the string resource is much
easier.

-Chuck

----- "Andrew Stitcher" <astitcher@redhat.com> wrote:

> From: "Andrew Stitcher" <astitcher@redhat.com>
> To: dev@qpid.apache.org
> Sent: Tuesday, June 29, 2010 4:59:44 AM GMT -05:00 US/Canada Eastern
> Subject: RE: Version and icon resources for Qpid cpp executables on Windows
>
> On Mon, 2010-06-28 at 17:25 -0400, Steve Huston wrote:
> > Hi Chuck,
> > 
> > > I'd like to add minimal resources, such as a version number 
> > > and an icon, to windows executables and dlls produced by 
> > > qpid-cpp. I see two paths to this goal and would like your 
> > > opinion on how to get there.
> > > 
> > > 1. Add minimal.rc and a qpid.ico files to each project.
> > >   * CMake commands are propagated through to the Visual 
> > > Studio projects.
> > >   * Version and Icon resources are compiled into resulting files.
> > > 
> > > 2. Compile the files as they are today with no version nor 
> > > icon resources.
> > >   * Post-build procedures patch the needed resources into the 
> > > exe and dll files.
> > 
> > Ok.
> > 
> > > Option #1 makes it harder for consumers of the qpid source 
> > > pool to get the version info straight from raw checkout. The 
> > > procedure would probably be to check out the sources but then 
> > > lay down the specific file versions for the build before the
> > 
> > I don't understand the need for laying down pieces by hand here.
> This
> > should all be automatable during the build.
> >  
> > > compile phase. Once the sources are in place, however, the 
> > > compiler does it's job and trustworthy images are built.
> > > 
> > > Option #2 is easier to create the exe or dll from raw 
> > > checkout. But then you have to trust your patch tool to do 
> > > the right thing.
> > 
> > And you would probably need to hand-edit something for the build,
> yes?
> > If so, that would be a source of errors at build time.
> > 
> > > I'm leaning toward option #2. It places the burden of adding 
> > > the resources only on projects that need them and not on 
> > > everyone. Is there a best-practice method to address this
> problem?
> > 
> > I'm not a release-engineering expert, but automation == good in my
> book.
> > Until I learn more about the pitfalls you've encountered or
> anticipate,
> > I'd lean to #1.
> 
> If I understand the proposals correctly, they are both equally
> automated
> as far as the build itself is concerned, but:
> 
> In proposal #1 what's you've got a whole bunch of .rc files (one for
> each exe/dll) each of which need to be maintained individually. You
> can
> factor out commonality into include files, but every dll would in
> principle need its own version number because the compatibility of
> each
> dll can change independently of the others.
> 
> In proposal #2 you've perhaps got a single file with the files and a
> version for each of them. then there would be a post build process to
> add the version resources (and maybe an icon for prettiness) to the
> exes/dlls.
> 
> I see the trade off as: #1 is more conventional, but it's unclear (to
> me
> at least) how it fits into the cmake process. #2 is much easier to
> maintain as all the version information would be in a single/simple
> place. #2 relies on non standard build tools, but requires other than
> that less "infrastructure".
> 
> I think we do actually need to put the version information in the
> dlls
> pretty soon, otherwise it becomes hard to do things like upgrade
> dlls.
> 
> I think #2 is a bit lighter and easier to maintain once set up, so I
> lean that way, but (and it's a big but) it depends heavily on having
> a
> reliable and available tool to do the patching.
> 
> Andrew
> 
> 
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message