Although it may be a bit later than desired, here are my two cents. This is
awesome, when will it be implemented and do you want a volunteer for use
case testing? I manage nearly two dozen installs so I would be happy to put
it through a tough set of paces and possibly help in coding.
On the more practice side, I think this is much need in the WiX toolset. It
enables another type of extension, one for simplification, that is at the
moment simply not worth taking the time to write as an extension. It gives
those who do not have experience in .net programming the opportunity to
create extensions. Furthermore, it would enable massive simplifications to
installers.
Simply to play devils advocate, (we are dealing with mold here <smile />) I
would also like to ask you about some of your concerns Rob.
Wit the one of the goals of the WIP being stated as, "Macros MUST NOT in
any way affect the logical structure of the code, the compilation process,
the linkage process, or any of the heuristics relating to how the package
is built. The total effect of using macros should sum up to visual
shorthands only.
"
Wouldn't this be an opportunity to kill 4 birds with a single stone?
The toolset gets a way to do simplified WiX (or at least aspects of it)
through the macro system with a transform that could be included in the
toolset and the code to do transforms that could be used for the
implementation of other mentioned aspects of simplified WiX. Developers get
the ability to write simple extensions without having to be familiar with
or duplicate large portions of the WiX toolset code. Everyone gets good
error handling because it has to work within the context of the WiX schema.
I would suspect that this would be easy to implement before WiX 5 that,
based on 3.0 to 4.0, might show up in 2020, which means developers aren't
waiting years for enormously useful functionality.
I would think that that the macros would be a stone that would be well
worth using. It obviously would have consequences, but I simply do not see
how the cons of this could outweigh the benefits. The extensions will still
be needed for things that need to work above and beyond the toolset, but
the macros speak to a mass of useful functionality that is simply
not practical to implement within the existing extension framework and
would likely still be comparably impractical to implement with an improved
extension framework.
P.S. I recommend we call it something other than mold... Perhaps flash,
glow, or sparkle to keep more with the naming of the other tools.
http://www.macmillandictionary.com/us/thesaurus/american/light has some
other good alternatives.
Thanks & Regards,
Joshua Messenger
Engineering Tech - Part Time
NxStage Medical, Inc.
350 Merrimack Street
Lawrence, MA 01843
Tel: (978) 332-8468
Fax: (978) 687-4800
jmessen...@nxstage.com
This email transmission is intended only for the use of the individual to
which it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify me immediately by replying to this
message or by contacting NxStage at 978-687-4700 and destroy all copies of
this message and any attachments without reading or disclosing their
content. Thank you.
On Tue, Apr 29, 2014 at 1:50 PM, Rob Mensching <r...@firegiant.com> wrote:
> Starting at the bottom , what you call the “FileTag” and “RegistryTag”
> model is what is prototyped in Simplified WiX. I proposed doing that to WiX
> toolset in v4.0 but it is a huge undertaking and didn’t fit. Maybe WiX v5.0.
>
>
>
> You are correct that the current extension model does not let you subclass
> existing elements. You can either add attributes to elements or you can
> take over the element completely. In either case, you probably have to
> duplicate way more code from the compiler than is ideally desirable. But it
> is still possible and could definitely be improved.
>
>
>
> For example, several times, I’ve considered making it so an extension
> element could contain elements from the WiX toolset. I’m not sure how hard
> this would be to implement. I’ve never looked into it because I never came
> across a use case.
>
>
>
> As for mucking with GUIDs, you’d almost always want to do that with a
> Binder extension not a Compiler extension anyway.
>
>
>
> Ultimately, I do not believe a macro language is the way to build an even
> more powerful extension model for the WiX toolset.
>
>
>
> _______________________________________________________________
>
> FireGiant | Dedicated support for the WiX toolset |
> http://www.firegiant.com/
>
>
>
> *From:* Tamir Daniely [mailto:tamirdani...@gmail.com]
> *Sent:* Tuesday, April 29, 2014 10:30 AM
> *To:* WiX toolset developer mailing list
> *Subject:* Re: [WiX-devs] RFC - issue #4375 - Preprocessor Enrichment -
> Parameterized Macros
>
>
>
> I totally agree regarding the need for strong typing and well documented
> behavior. This is exactly my mind-set and the reason why I didn't want to
> to just have macros behave like a smart text capturing mechanisms.
> I was aiming more for an easy way for non-programmers to deliver
> extensions and modules by composing them using the WiX schema itself.
>
> But putting the reliance on .Net coding to write extensions aside for a
> second. A major problem is that the current extension model is very limited
> in the sense that it only allows adding self contained functionality.
> Because the compiler logic is really just a giant static module, extensions
> can't integrate into the existing schema.
>
> Let me give a few examples for what I mean because this is saying a lot.
> And please correct me if I missed something in the code.
>
> Say I wanted to make a tag that replaces component and implement some
> specific GUIDing scheme. For example by examining an assembly and
> generating a GUID from the assembly name, or by accessing a persistent
> store where component GUIDs are cached by user specific logic. I can't
> accomplish this sort of thing because a component is a specific code entity
> with lots of dependent code entities and I'll need to implement these
> details. But that extension point doesn't exist. I can't have my extension
> implement an IDirectoryProvider to it's descendants. My extension actually
> can't have descendants because I can't recurse back to the core parsing. I
> can't have my <orgExt:OrgCA /> inherit from <wix:CustomAction />. And on
> and on...
>
> A very good example for the kind of stuff this causes is
> ICompilerExtension.ParsePossibleKeyPathElement() which had to be added when
> it could very well have been just an ICanProvideKeyPath interface that is
> implemented by FileTag & RegistryTag and can then be just as well
> implemented by extension tags. ParsePossibleKeyPathElement is an interface
> of an entity expressed as an implementation detail instead of an interface
> of an entity just because the entity wasn't defined in the first place.
>
> So seeing this in the code I go to the idea of a preprocessor macro
> feature. But that's not a best way to achieve these goals just as writing
> extensions that are self contained blobs of logic isn't either. It's just
> the most realistic against the current compiler design.
>
>
>
>
>
> On Mon, Apr 28, 2014 at 7:53 PM, Rob Mensching <r...@firegiant.com> wrote:
>
> Again, I appreciate the amount of detail you put into the WIP already. I
> think this might be a case where it would have been better to discuss the
> high level concept here first but you did a good job describing the feature.
>
>
>
> Overall, I’m against adding a macro language to the WiX toolset. I already
> try to discourage use of the preprocessor. It seems like many of the
> language benefits of macros can already be attained by creating an
> extension. Admittedly, creating an extension takes a bit more work but you
> get a strongly type, documented enhancement to the WiX toolset that can do
> very robust error handling. I’d rather we tackle any issues with the
> extension model than create a macro system in the preprocessor.
>
>
>
> That said, you certainly could create a project to create the preprocessor
> extension that implements this feature. If people flock to the concept then
> we’d reconsider inclusion in the core toolset. This is similar to what
> happened with Neil’s extended wixstdba. He added a couple features that
> people seemed to find quite useful that were eventually integrated into the
> WiX toolset.
>
>
>
> _______________________________________________________________
>
> FireGiant | Dedicated support for the WiX toolset |
> http://www.firegiant.com/
>
>
>
> *From:* Tamir Daniely [mailto:tamirdani...@gmail.com]
> *Sent:* Friday, April 25, 2014 8:41 PM
> *To:* wix-devs@lists.sourceforge.net
> *Subject:* [WiX-devs] RFC - issue #4375 - Preprocessor Enrichment -
> Parameterized Macros
>
>
>
> Hi,
>
> I'm sorry for the delay in sending this, we all still have jobs :).
>
> First off, the original issue on tinybugs:
> http://wixtoolset.org/issues/4375/
>
> Second, the draft WIP on my fork
>
> https://github.com/Tetnacious/site/blob/master/root/src/documents/development/wips/4375-parameterized-macro-tags.html.md
>
> For the general idea, please read the User Stories and Proposal sections
> of the WIP.
>
> Please discuss this idea.
>
> * How much would you like to see this feature in WiX?
>
> * Suggestions of better ways to achieve the same goals?
>
> * Suggestions, remarks or requests regarding the syntax of the macros.
>
> * Suggestions or remarks regarding implementation.
>
> * Any other thoughts.
>
>
>
> My thoughts on the implementation.
>
> I originally proposed that it'd be written as a PreprocessorExtension. I
> have one major problem with this approach and that is the early expansion.
> Currently, preprocessor extensions can only access the full document after
> the regular preprocessing. This is both counter-intuitive and limits the
> functionality and reuse potential of the macro.
>
> Consider for example that in my macro I want to get the TargetPath of a
> referenced project just using the project name. I would write something
> like `$(var.$(mac.ProjectName).TargetPath)` which will fail because of the
> early expansion since the preprocessor is not aware of the variable and the
> extension can't supply it because it is call specific.
>
> So long story short, in my opinion macros should be expanded before
> standard preprocessor commands, and so a new extension point is required on
> IPreprocessorExtension and in Preprocessor. Something like
> PreprocessDocument but before parsing the variables and conditionals. And
> that is the only addition to WiX that the feature requires in my opinion.
>
>
>
> Regarding Votive. It seems only natural that we give the user some
> documentation syntax on the macro definition which will show up in the
> tooltips and autocomplete, otherwise there will be a heavy overhead of
> constantly checking the macro source when using it. Also, I think that a
> basic "Go-To"\F12 functionality will be nice and sort of expected. And on
> the same breath we could add the go-to functionality to other places like
> XXXXXref tags and include directives.
>
> Regarding the Votive build. Obviously, if the whole thing is implemented
> as a preprocessor extension, then there's no need for any change to the
> Votive build process.
>
>
>
> Best Regards,
> Tamir Daniely
>
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
