Okay, sounds like you are solely focused on improving the extensions. In
the past the extension build was horribly designed. Rather, it's design
changed over time and work was never done to reconfigure the whole thing to
make it better.
The points your making are inline with my #2 point below. I reorganized *a
lot* of the extensions in WiX v3.7 to make them build correclty. Most
importantly, I was trying to get *incremental* build correct since it was
massively frustrating when editing any part of an extension required a
clean build of the whole system. We just lived with that for a while since
fixing it was work.
Take a look at the Gaming extension or the Bal extension. Both of those are
designed better. The IIS and SQL extensions need their code to get
integrated into their correct places under src\ext\. Ultimately, the
src\ca\ tree should go away since no CustomAction in WiX should live
without a helper extension.
Building WiX should not affect the version of WiX you have installed. I do
remember Votive doing some bad stuff a while ago but wix37+ definitely does
not have that issue (I'm running with WiX v3.7 RTM installed plus builds
for 37,38,40).
At the same time, the WiX build should not require you to install some
version of the WiX toolset so you can build what will be the next version
of the WiX toolset. That ends up with cycles I don't even want to think
about.
Again, back to #2. It should be relatively straight forward to get the
various extension projects building as you describe in Visual Studio. Would
you like to try with something simple like the Gaming extension so it
doesn't require one full build before being opened in WiX? The IIS and SQL
stuff will require use of a blowtorch to cut the CA DLL apart so that can
follow later.
Note: I expect the DevBundle is not necessary to get extension realted
code building.
Note2: thmviewer probably just requires a project reference to dutil and I
expect it will work.
Finally, as I noted, the goal is to get contributions into the WiX toolset
to be as easy as possible. If making it easy to get bug fixes and features
into the WiX toolset makes it harder for someone to lift code out of the
WiX toolset and not contribute back, I don't mind that. If we optimize the
other way around, then we're putting forth a policy that is designed to
fragment the community. I don't see how that would help us right now.
Am I missing something?
On Mon, Feb 18, 2013 at 9:06 AM, Neil Sleightholm <n...@x2systems.com>wrote:
> I agree that is simple to build the whole thing now but that isn’t
> really my point – it is not very easy to pick up one area in Visual Studio
> and work on it, you need to know what to include and then what to get out
> of the release area to actually test it. In my experience it doesn’t work
> in the “normal” Visual Studio way.****
>
> ** **
>
> So to take my example of changing IIS, you need to build the C++ and the
> WiX extension (and the wixlib) and they are in different areas, I think I
> know my way around the code but I end up changing source and then running
> the full build which doesn’t feel right to me. If you try to configure a
> solution the project files are so heavily customised you seem to have to
> include everything.****
>
> ** **
>
> I am not sure if this is still the case but in the past if you built
> everything it could break your existing installation of WiX as it
> registered things and changed paths (IIRC correctly this was related to
> Votive). I suppose you could argue you need a dedicated environment but
> that seems bit excessive. ****
>
> ** **
>
> It just feels to me that it would be easier if you could just open the
> extension projects without building everything and it would reference the
> WiX SDK you have installed. If you are working on the WiX core then I think
> building it all isn’t as big a problem. The extensions are probably the
> biggest area but there are some other bits that I have struggled with; for
> example in 3.6 I wanted to try and enhance the theme viewer but in the end
> I gave up trying to load and debug it (I haven’t tried in 3.7/3.8 may be it
> is easier).****
>
> ** **
>
> >> I'm not terribly interested in doing work that makes it easier to
> appropriate code out of the WiX toolset.****
>
> I agree but my point is that if I make a change to WiX and that isn’t in
> the core product it has to be in my source-control until it is; if I can’t
> do that easily then I have to find an alternative. I wouldn’t expect anyone
> else who needs to look at an issue with my code to have to learn how to
> build all of WiX. The devbundle might help this but for the extensions that
> seems overkill as everything you need is already in WiX. ****
>
> ** **
>
> As I said just my opinion and maybe I am in the minority.****
>
> ** **
>
> Neil****
>
> ** **
>
> *From:* Rob Mensching [mailto:r...@robmensching.com]
> *Sent:* 18 February 2013 15:40
> *To:* Windows Installer XML toolset developer mailing list
>
> *Subject:* Re: [WiX-devs] Building WiX Code****
>
> ** **
>
> Sorry for the delay in response. I've been out of the country then our
> whole family was hit by the flu. I'm the last to recover.****
>
> ****
>
> I think we should focus on making it easier to build and contribute to the
> WiX toolset. I'm not terribly interested in doing work that makes it
> easier to appropriate code out of the WiX toolset. That isn't likely to
> make the WiX toolset better for everyone.****
>
> ****
>
> In that light, I am very interested in understanding what is difficult
> about building the WiX toolset?****
>
> ****
>
> From WiX v3.7+ you should only need VS2010 installed (WiX v3.8+ should
> also support VS2012 only if you prefer). Then run "msbuild" from the root
> of the project and everything will build once. That takes ~5 minutes on
> my not-terribly-fast machine. After that, you should be able to build any
> sub-directory in less than a minute.****
>
> ****
>
> That said there two things I can think of that may be issues:****
>
> ****
>
> 1. The build should turn off stuff if you don't have the pre-requisites.
> Bugs where this is not true are usually found by trial and error since it's
> challenging to get build machines in all the different configurations. If
> you find that a known good build fails, send email to wix-devs and we'll
> help track down what is wrong.****
>
> ****
>
> 2. There is an opportunity to improve the project dependencies. I did the
> migration from NAnt to MSBuild in the early days of WiX v3.7 by myself.
> That was over a decade's worth of build system crud that I tried to clean
> up in one pass. Since our NAnt build didn't do much of anything with
> dependencies, I did not have a lot of data when converting to MSBuild. If
> people wanted to follow up and help get project reference dependencies
> correct to make it easier to build subsets of the WiX toolset faster, that
> would be awesome.****
>
> ****
>
> I expect the issues are either experiences with the pre-WiX v3.7 build
> system or issues in #1 above. We can fix #1. <smile/>****
>
> ****
>
> I'm going to go one step further too. I've just created a branch in the
> WiX repository called "devbundle". In that branch, I've started to create a
> Bundle that should install all the pre-requisites to building the full WiX
> toolset *except* for Visual Studio itself. That way there should be no
> question what needs to be installed to build everything in the WiX toolset.
> The answer is "Install the WiX Toolset Developer Bundle" (and it will error
> if you don't have an appropriate VS installed). This will also help me when
> setting up new build machines. <smile/>****
>
> ****
>
> Are there other things that would make it easier to build the WiX toolset?
> ****
>
> ****
>
> ****
>
> ****
>
> ** **
>
> On Thu, Jan 31, 2013 at 10:33 AM, Neil Sleightholm <n...@x2systems.com>
> wrote:****
>
> >> almost-but-not-quite trivial to build****
>
> ****
>
> I think that sums it up, it is still not trivial you have to install loads
> of stuff some of which you might not need but who knows. If the extensions
> were standalone it would be obvious what you needed and if the code built
> you would know you had everything to develop just the extension you were
> interested in. The current layout doesn’t even easily load into VS so this
> doesn’t help, it seems to be all or nothing.****
>
> ****
>
> IMHO lots of lot self-contained extensions is the way to go – someone
> mentioned a “Contrib” concept, I think this would be a good step forward.
> For example, I am sure if you could load the IIS extension solution and it
> referenced the installed libraries people would be more inclined to
> contribute.****
>
> ****
>
> Just my opinion…****
>
> ****
>
> Neil****
>
> ****
>
> *From:* Bob Arnson [mailto:b...@joyofsetup.com]
> *Sent:* 30 January 2013 03:53****
>
>
> *To:* wix-devs@lists.sourceforge.net
> *Subject:* Re: [WiX-devs] Building WiX Code****
>
> ****
>
> On 19-Jan-13 18:24, Neil Sleightholm wrote:****
>
> I appreciate the issue of splitting the code but in my opinion it would
> be worth it, as I see it it is currently too complex. I have been trying to
> build WiX code for many years and it has never been possible to resubmit my
> changes because the codebase is not structured in a way that makes it easy
> so I have to rely on submitting bugs and hoping you guys can fix them. For
> example, the IIS site code bug, the IIS log folder bug, IIS mine types – I
> solved these years ago but by writing extra code rather than enhancing the
> core code.****
>
> Hence my confusion: Why would making it easier to build isolated parts
> make it easier to contribute to WiX? Granted, it was a PITA to get a build
> machine for WiX <=v3.6 but with the MSBuild work in v3.7, it's
> almost-but-not-quite trivial to build. So build it once and you can hack on
> any part easily.
>
> ****
>
> -- ****
>
> sig://boB****
>
> http://joyofsetup.com/****
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs****
>
> ** **
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - 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
>
>
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - 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
