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 <[email protected]> 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:[email protected]]
> *Sent:* Friday, April 25, 2014 8:41 PM
> *To:* [email protected]
> *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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
