InstallerGeek created the topic: Using Heat multiple times => Duplicate symbols
Hello all,
I am using heat to generate the source for two .wixlibs which are lighted together with some other pieces to form my final MSI. Heat is used on two different directories at build time. One of these directories holds all of my language specific files “/localized/” and the other holds all of my language neutral files “/neutral/”. Creating a setup this way allows me to generate the language neutral .wixlib just once for every locale I support.
The problem is that the directory structure within those directories has some (but not complete) overlap. e.g.
localized
foo
greeneggs
bar
neutral
foo
ham
becomes on the user’s computer
installdir
foo
greeneggs
ham
bar
This gives me a duplicate symbol error at foo when I try to link the two wixlibs together. I can’t just throw away the directory fragments from one heat run because neither structure is a subset of the other. I also don’t want to tell light to suppress the duplicate symbols error (and I don’t know that that will produce a working MSI). Really the only solution I’ve come up with is to use XSLT to eliminate all of the directory elements from the first two runs and then run heat again against the combined result and use XSLT on that third run to eliminate all of the non-directory elements.
That seems suboptimal at best. Anyone have any better ideas?
applicationPackaging replied the topic: Re: Using Heat multiple times => Duplicate symbols
Hi Kyle,
What about using the XSLT to change the duplicate
I do something like this when I first create a setup project–I do not use HEAT dynamically at build time. I like to have the directory structure laid out in one place where it’s easier to visualize how it will look on the target system.
applicationPackaging replied the topic: Re: Using Heat multiple times => Duplicate symbols
How about using XSLT to change the
InstallerGeek replied the topic: Re: Using Heat multiple times => Duplicate symbols
Yeah, this is more or less what I’m doing. The issue is that I still need to define the directory structure somewhere. Zach suggests defining it manually which is probably the best solution but unfortunately isn’t really an option for what I’m doing. What would be ideal is if light would handle a duplicate symbol definition if the symbols are identical (same ID and attributes, etc.) by outputting the symbol once instead of choking. Of course, there may be good reasons I haven’t thought of not to do that – I’m not sure. I’m hoping that someone has solved the same problem in a manner that avoids this problem.
applicationPackaging replied the topic: Re: Using Heat multiple times => Duplicate symbols
Looking at your situation, this is what looks to me to be your solution:
1- I’m assuming that your transformed heat outputs don’t have any Directory elements with an Id of either localized or neutral. Remove them if they exist in your transform.
2- Under your Product element (or some other manually authored location that is linked into your final MSI):
3- In your transformed localized sources from heat:
…
…
…
…
4- In your transformed neutral sources from heat:
…
…
…
So your transform will need to look at the directory tree that heat produces and transform that to get the above results (by altering at and above the level of the children of installdir and leaving the others unless you start creating some of them as well).
If you have files in installdir as well as the above subdirs you will need to also declare a DirectoryRef for that directory so that the fragment(s) from heat can be linked into your wixlibs. The only directories you have to transform/manually deal with are those that are in common. The above lets you simply harvest the unique directories as they are laid out without having to manually deal with them.
InstallerGeek replied the topic: Re: Using Heat multiple times => Duplicate symbols
Hey Everyone,
Why can’t you heat the sub directories “greeneggs” and “ham” directly and use the -srd and -dr FOO switches? I do understand if there are additional sub directories this might be a bit more difficult. However, you could re-arrange your source directories to handle these issues if necessary, no?