On 02-Jan-15 11:50, Tunney, Stephen wrote:
I have some good news regarding the work I’m doing with melt.
It appears as though all other steps (light, torch, pyro) all seem to
carry the changes forward from melt and applying the patch in Orca
shows that the Binary data has been updated.
All I need is some weigh in from Bob as to what to call the sub folder
OR create a breaking change in melt for 3.10 or 4+ (I’ve currently
forked 3x on github).
Here's what I left on the pull request:
Can't make this change [DTF change] in v3.x since it's a significant
behavior change for all users of this method in DTF. I think the best
approach for v3.x is to add a switch to melt to specify the binary
output directory. If not specified, don't extract binaries. And that
could be all internal to melt rather than a DTF change. Another approach
would be to do kinda what dark does and extract files and binaries to
their own subdirectories. That's also a behavior change but I could be
convinced it's OK...
Anyone care if we changed how Melt wrote its output? On the surface,
Melt still does what it did: Extract the content and update the .wixpdb
to match. The output tree would be different, so it would require
someone using it to change how they update the output tree with new
binaries.
The more I talk about it, the bigger a change it seems...
--
sig://boB
http://joyofsetup.com/
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
