Let me make sure I'm going to do this right...
(I think I'd end up with about 100 FeatureRefs at the end.)
Say, I have this: (This is the largest of the 10 "toolchain" fragments
that get made, the rest run from 2 to 300 files in size)
<Fragment Id="F_perl" ...>
<Feature Id="Feat_perl" Level='1' Display='hidden'>
<!-- about 900 Components, I think - hopefully I wouldn't need to
split this one in two. I'll have to check. -->
</Feature>
</Fragment>
And this (this would be an example of one of the 90 or so modules and
libraries that I add on top of Perl)
<Fragment Id="F_IO_Compress_Gzip" ...>
<Feature Id="Feat_IO_Compress_Gzip" Level='1' Display='hidden'>
<!-- about 2-60 Components each -->
</Feature>
</Fragment>
And then in the main file, I would then have
<Feature Id='Complete' Title='Strawberry Perl 5.10.1.0 Beta 1'
Description='The complete package.' Level='1'>
<FeatureRef Id='Feat_perl' />
<!-- FeatureRef's and what ComponentRef's are left for non-file stuff
(10-100?) later -->
<FeatureRef Id='Feat_IO_Compress_Gzip' />
</Feature>
Would that be how I would do that? (I'm already creating the 100
separate .wxs files with a Fragment in each, it looks like I just need
to make most of the Fragment tags contain a Feature tag.)
--Curtis
--
Curtis Jewell
swords...@csjewell.fastmail.us
%DCL-E-MEM-BAD, bad memory
-VMS-F-PDGERS, pudding between the ears
[I use PC-Alpine, which deliberately does not display colors and pictures in
HTML mail]
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
