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<mailto: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<mailto:b...@joyofsetup.com>]
Sent: 30 January 2013 03:53
To: wix-devs@lists.sourceforge.net<mailto: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<mailto: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
