[wix-devs] Burn micro repo(s)

[Sean Hall]

I think I'm good with your layout, with one little tweak that
IBoostrapperEngine.h and IBootstrapperApplication.h should be in the Burn
interface repo instead of staying in balutil with the rest of balutil's
headers. For the initial setup, I would just keep all of BootstrapperCore
as is in the Burn interface repo and then later we'll need to create a new
project in the BalExtension for the code we're able to move out of
BootstrapperCore.

On Thu, Dec 20, 2018 at 10:43 AM Rob Mensching via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> I think I followed all that but I'm not sure what the final proposal is.
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Thursday, December 13, 2018 10:36 AM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] Burn micro repo(s)
>
> It used to be the Burn headers and
> IBootstrapperApplication/IBootstrapperEngine were the same thing. That's
> no longer true - the Burn headers are binary,
> IBoostrapperApplication/IBootstrapperEngine are WiX provided abstractions
> around the binary interfaces. Today, the native
> IBoostrapperApplication/IBootstrapperEngine interfaces are in the balutil
> headers, and managed IBoostrapperApplication/IBootstrapperEngine are in
> BootstrapperCore. I think it will be possible to forget to update those
> interfaces now that they're not used by the engine, but less likely to only
> update the native without the managed (and vice versa). Of course they are
> supposed to be all updated together - but updating the interfaces will
> force you to also go and update the implementation.
>
> On Thu, Dec 13, 2018 at 12:25 PM Rob Mensching <rob at firegiant.com> wrote:
>
> > That sounds right. The next analysis is what chunks of code change at
> > the same time and can be grouped together.
> >
> > In that list below:
> >
> > 1. The BootstrapperCore and Burn headers are most likely to change
> > together (it's actually easy to forget to update BalExtension today
> > after updating burn/inc).
> > 2. Naturally the balutil headers and lib change together.
> >
> > All of this is how I came up with my a.-d. list of repos below.
> >
> > -----Original Message-----
> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
> > Sean Hall via wix-devs
> > Sent: Wednesday, December 12, 2018 9:34 PM
> > To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> > Cc: Sean Hall <r.sean.hall at gmail.com>
> > Subject: Re: [wix-devs] Burn micro repo(s)
> >
> > People building bundles with WixStdBA need core WiX + BalExtension.
> >
> > People building an MBA need BootstrapperCore. To build a bundle with
> > that they'll also need core WiX + BalExtension.
> >
> > People building a native BA that uses balutil need Burn headers +
> > BalUtil headers + BalUtil lib. To build a bundle with that they'll
> > also need core WiX.
> >
> > People building a standalone native BA need Burn headers.  To build a
> > bundle with that they'll also need core WiX.
> >
> > On Wed, Dec 12, 2018 at 10:44 PM Bob Arnson <bob at firegiant.com> wrote:
> >
> > > Might help to lay out the NuGet packages we see being published so
> > > we can graph out the dependencies for (1) people building bundles,
> > > (2) people building native BAs, and (3) people building managed BAs.
> > > I like the cleanliness of the interfaces separation but they're so
> > > tiny in Burn, it smells like overkill if we can manage the packages
> > > some
> > other way.
> > >
> > > -----Original Message-----
> > > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
> > > Sean Hall via wix-devs
> > > Sent: Tuesday, 11 December, 2018 22:09
> > > To: Rob Mensching <rob at firegiant.com>
> > > Cc: Sean Hall <r.sean.hall at gmail.com>; WiX Toolset Developer Mailing
> > > List <wix-devs at lists.wixtoolset.org>
> > > Subject: Re: [wix-devs] Burn micro repo(s)
> > >
> > > Breaking balutil out to its own repo totally makes sense.
> > >
> > > I think I see where you're trying to go with BalExtension/core
> > > (BootstrapperCore.dll) going into the Burn interfaces repo.
> > > Eventually we want to split BootstrapperCore.dll into
> > > MBA.Interfaces.dll and MBA.Implementation.dll, with MBA.Interfaces
> > > in the Burn interfaces repo and MBA.Implementation in the
> > > BalExtension repo. I'm a big fan of doing things iteratively if
> > > possible, so I would rather not try to do that when we initially set
> > > up these 4 repos. Or if we really wanted to at least create the new
> > > MBA interfaces assembly, only put IBootstrapperApplication and
> IBootstrapperEngine in there to start with.
> > >
> > > If we are putting balutil and BalExtension in seperate repos, and
> > > putting managed interfaces into the Burn interface repo, then the
> > > native IBootstrapperApplication and IBootstrapperEngine headers
> > > should also go there. And possibly IBAFunctions. Though to be
> > > honest, I'm not seeing the use case for anyone using
> > > IBoostrapperApplication/IBootstrapperEngine
> > > without balutil, or the managed ones without the managed BAL
> > > implementation.
> > >
> > > On Tue, Dec 11, 2018 at 7:42 AM Rob Mensching <rob at firegiant.com>
> wrote:
> > >
> > > > Some thoughts (if they are incoherent, I blame my current fevered
> > state):
> > > >
> > > > 1. deputil should be tossed in with dutil. It isn't big enough to
> > > > live on its own. I thought I did that already but did not.
> > > >
> > > > 2. If we break it out, I think:
> > > >   a. Burn Interfaces - wix4/src/burn/inc/* +
> > > > wix4/src/ext/BalExtension/core (and maybe work to reduce MBA core
> > > > to just some interfaces)
> > > >   b. Burn engine - /engine, /stub, /samples
> > > >   c. balutil
> > > >   d. BalExtension - obviously, minus /core
> > > >
> > > > Given the change patterns of the code, I think that would work out
> > > > really well (once the repos are created <smile/>).
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf
> > > > Of Sean Hall via wix-devs
> > > > Sent: Saturday, December 8, 2018 8:45 PM
> > > > To: WiX Toolset Developer Mailing List
> > > > <wix-devs at lists.wixtoolset.org>
> > > > Cc: Sean Hall <r.sean.hall at gmail.com>
> > > > Subject: [wix-devs] Burn micro repo(s)
> > > >
> > > > I think these are the Burn related folders that we still need to
> > > > move into micro repos:
> > > >
> > > > wix4/src/burn
> > > > wix4/src/ext/BalExtension
> > > > wix4/src/libs/balutil
> > > > wix4/src/libs/deputil
> > > >
> > > > The easiest way would be to just throw them all into one repo.
> > > > Otherwise, we'll have to start looking at all the different parts.
> > > > Here's what I think are all the pieces:
> > > >
> > > > wix4/src/burn
> > > >     burn engine (/engine - engine.lib plus headers)
> > > >     BA interface headers (/inc - BootstrapperEngine.h and
> > > > BootstrapperApplication.h)
> > > >     burn stub (/stub - burn.exe)
> > > >     samples (/samples)
> > > > wix4/src/ext/BalExtension
> > > >     actual extension (/wixext, /wixlib, /wixlib_arm)
> > > >     MBA host (/mba/host - mbahost.dll)
> > > >     MBA core (/mba/core - BootstrapperCore.dll)
> > > >     WixStandardBA (/wixstdba - wixstdba.dll)
> > > >     sample BA Functions (/samples) wix4/src/libs/balutil
> > > >     base native BA, BA utility methods (balutil.lib)
> > > >     BA Functions interface header (/inc - BAFunctions.h)
> > > > wix4/src/libs/deputil
> > > >     deputil.lib
> > > >
> > > > If we're going to split it up, I guess it would be one repo for
> > > > the BA interface headers, one repo for the Burn engine and stub
> > > > and samples (and deputil?), and one repo for the rest.
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>