1. Is there real value putting the method in DTF if only Melt uses it?
2. I agree with you and Bob about not breaking WiX v3.
3. Do we need the “-sextract” (what kind of tract?) in v4? Can’t we just
do what it does and not bother with suppression? Or is suppression a *really*
important feature?
_______________________________________________________________
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
From: Stephen Tunney [mailto:stephen.tun...@gmail.com]
Sent: Saturday, January 3, 2015 5:36 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table
for patching
Ok, so here's my pitch:
v3.x would get a couple of new flags
-xn (extract in new directory format) <patch>
-xb (extract binaries, does not get squashed by -sextract and uses old path
format) <path>
Execution of the ExtractBinaries method would happen in Melt exclusively even
though the actual Method is in DTF (no one else would call it). This makes it
an easier merge to 4.x.
Options are mutually exclusive. This would maint
v4.x
Just change to match dark and accept it as a breaking change. -sextract would
suppress all extraction, including Binary, Icon, etc.
Thoughts?
On Sat Jan 03 2015 at 4:12:39 PM Bob Arnson
<b...@joyofsetup.com<mailto:b...@joyofsetup.com>> wrote:
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<mailto:WiX-devs@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wix-devs
------------------------------------------------------------------------------
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
