?

Log in

No account? Create an account
 
 
01 March 2007 @ 09:36 am
ARGH!!!  
We are using the ICU libraries in our code at work to handle unicode stuff. This is something that was apparently devloped by IBM before being put up on SourceForge. This worked great for about a year, but then the manager of our project decided that we really ought to make as many of the dlls we use as possible into Windows Side-by-Side assemblies. This involves doing some theoretically minor rewrites to the build process without actually changing the code itself. This was pretty easy for all of the projects, except ICU.

When creating this project IBM managed to create _circular_ dependencies.

There are DLLs A, B and C. B depends on A and C, and C depends on A as well. There are four projects directly responsible for building these dlls, and 31 projects responsible for building some other dlls we don't use and a whole lot of auxiliary stuff.

Project 1 builds a stub of dll A. Project 2 builds dll B. Project 3 builds dll C. Projects 4-34 build all the other dlls and auxiliary files. Then Project 35 rebuilds dll A using the auxiliary files.

This already sounds complicated enough, except that the auxiliary files to rebuild dll A depend on dlls B and C! Which depend on A! They get around this with the stub file in the normal configuration but trying to turn this into Side by Side assemblies makes everything blow up. Assemblies are a pain to install, and so far i haven't found any safe way of doing so other than through an msi. (I'm reluctant to just dive into the Windows folder tree and start renaming files and folders willy-nilly without some indication from a knowledgeable authority that it won't completly break my computer.) So during the "normal" build process building the stub of A and the dlls of B and C works fine, as does building all the auxiliary files. But then we get to the last project. It tries to use the auxiliary files, they try to load dlls B and C, they try to find dll A, but they look in the Windows\WinSxS folder rather than at the dll sitting in the same folder and die. I haven't found any way to make an assembly dependency optional, so the only way i've figured out to get around the issue is to build the project in the normal configuration, then switch over to the assembly configuration (which compiles to the same folder) and compile every thing in a different order. Rebuild project 1 first, then skip to project 35 so the auxiliary files can use the normal versions dlls B and C before they get overwritten, _then_ build projects 2 and 3.

This method works great, but we can't automate it. With Visual Studio 8 at least you can set a lot of things differently for different configuration options, but the build order is solution wide. We tried setting up a build file using devenv to build the individual projects in the right order. However selecting project 35 and doing "Project Only -> Rebuild Only Project 35" in Visual Studio rebuild only that project, but running devenv ICU.sln /project "Project 35.vcproj" looks at the dependencies and starts rebuilding most of the other projects as well.

Luckily since this is an outside library that we don't change at all (except for this whole assembly thing of course) i think we're going to end up rebuilding everything by hand and putting the resulting files up on a networked drive where the other builds can reference them, but the entire thing is just icky icky icky =P

Oh, and needless to say this roundabout method makes building the x64 version on a x86 machine totally impossible, even before the added complexity of assemblies =P
 
 
Current Mood: frustratedfrustrated
 
 
 
Dieppe: Goodbyedieppe on March 1st, 2007 06:56 pm (UTC)
That's funny! I was the ICU porting person a few years back. Some of it was compiling on our platforms, but fitting it into our work environment as well. Also did port it to some UNIX platforms that weren't previously supported.

What fun for you! :) We just use them as dll files. Anyway, good luck.

Chaos Never Blinkssithjawa on March 1st, 2007 10:27 pm (UTC)
I hope this wasn't the root of the complaint you voiced in your other post, because if so, facepalm facepalm facepalm.

Or maybe I hope it was, because if so, you don't have to worry about it for *other* projects?
DonAithnendonaithnen on March 1st, 2007 11:05 pm (UTC)
Well i hope you decided you hope it was, cause that's what it was, i hope. :)