today's git broke winetricks gecko :-(

[Jacek Caban]

Vincent Povirk wrote:
> On Tue, Nov 17, 2009 at 9:54 AM, Peter Urbanec <winehq.org at urbanec.net> wrote:
>   
>> There's a lot of talk about the new Gecko requirement. At the end of the
>> day, adding the .cab file to a binary distribution was a trivial 10 minute
>> exercise. It took another 20 minutes to test everything and figure out that
>> the wiki page was wrong and the .cab file needs to go in
>> $PREFIX/share/wine/gecko NOT in $PREFIX/share/gecko. The wiki page is now
>> fixed, so it really should be trivial to add the gecko runtime to most
>> binary distributions.
>>     
>
> While I am much less annoyed now that things are working, I'd still
> like to see an option for specifying the .cab file path at run time,
> and for disabling the dialog completely. Maybe I'll write some
> patches.
>   

I'm not fan of this idea, but we may talk about patches once they will 
exist. For your (unusual IMO) case of multiple installations it might be 
worth to consider a special target for 'make install' that would check 
if gecko is available in $build_dir/../gecko and copy it if it does.

> And apparently the difficult build process is being worked on but is a
> hard problem to solve, so I'm satisfied with that. It's good to know
> there aren't any real closed-source components needed to build, just
> unusual versions / changes to open-source components.
>
> It sounds like the the unusual version requirements and hacks are
> mostly the result of bugs in other projects that are tracked in their
> bug trackers, and of the need to build a PE gecko on Linux rather than
> a winelib gecko (which is itself needed because of the difficult build
> process, which is because of bugs in other projects). Is this
> accurate?
>   

Yes, it's true except for mingw. I've filled one bug for them and there 
was no interest. I also can't send them patches because they don't agree 
with the way Wine includes are created. I've chosen to provide our own 
includes for these problems that are fixed mingw headers or just Wine 
replacements.

I also don't see much point in winelib builds so I don't plan to work on 
it myself. It will make things harder to support. The only real point I 
can see is if we wanted to provide a package for architectures are not 
supported by PE. Anyway, once mingw builds will work good, it should be 
much easier to change.


Jacek