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<mailto: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<mailto:tamirdani...@gmail.com>]
Sent: Friday, April 25, 2014 8:41 PM
To: wix-devs@lists.sourceforge.net<mailto: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<mailto: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
