Re: Fwd: Plans for GTK+ Bundles for win32 and win64?

Let me first remind everyone that has a good summary of all
things that are being discussed here. We're kind of heading in four
different directions at once (fedora-mingw, MSVC, native mingw, OBS)
so it's important we keep track :)

On Thu, Sep 8, 2011 at 1:12 PM, John Stowers
<john stowers lists gmail com> wrote:
>> It takes a "build description" file like:
>> downloads required files, extracts them, applies transformations if
>> requested,
>> repacks, etc until finally a .msi is produced.
>> It is currently capable of packaging zips from and also
>> Python
>> distutils generated .msi files (for PyCairo, PyGTK, PyGObject, etc).
>> Cleaning this up and making it more generic and easier to use is
>> something
>> I've been wanting to do for a long time now...
> Cool!
> note: these are my uninformed ideas, I have not actually seen the
> implementation for the methods you describe...
> I think JHBuild is *almost* able to do this itself. If the binary/zip
> module type patch was applied to JHbuild then I think this would not be
> too much work to complete.

I'm actually not sure the binary module type is such a good idea any
more. It used to be the case that in my windows fork of jhbuild the
binary module type was used to upgrade and patch various parts of MSYS
and get hold of deps like libpng, zlib, etc. Since then, mingw-get has
arrived and the general state of MSYS is a lot stronger, to the point
where it doesn't really need patching at all any more. As for the deps
- I reckon the way forward is to come up with a script that will bring
together all of the build deps for the Gtk+ stack and provision them
for developers either in a mingw-get repo, or just as a massive "the
entire build environment" .ZIP file. I'm thinking of this from a
mingw-only point of view, but presumably the same script could
generate a build environment for MSVC too with a little extra code.

> AIUI JHbuild now tracks installed files and can create a manifest. This
> manifest + JHbuild supporting binary/zip module types would give you all
> the meta information to write msi/wix/nsi installers.

I agree that this should be possible and would be awesome. Not sure
how the binary module type is useful here - am I missing something?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]