qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject RE: Version and icon resources for Qpid cpp executables on Windows
Date Tue, 29 Jun 2010 08:59:44 GMT
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


Mime
View raw message