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:[email protected]
