mingw-cross-env-list
[Top][All Lists]
Advanced

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

Re: [Mingw-cross-env-list] To build shared objects as option


From: Tuukka Pasanen
Subject: Re: [Mingw-cross-env-list] To build shared objects as option
Date: Sun, 29 Dec 2013 16:43:18 +0200

Hello,
I was just wondering should I first send patches or pull requests to
update FFmpeg and xine-lib in MXE master. Then do the same all the
other added packages.

Thanks for advice,
Tuukka

2013/12/27 Tuukka Pasanen <address@hidden>:
> 2013/12/26 Tony Theodore <address@hidden>:
>>
>> On 16 Dec 2013, at 07:40, Timothy Gu <address@hidden> wrote:
>>
>>> On Sat, Dec 14, 2013 at 11:32 PM, Tuukka Pasanen
>>> <address@hidden> wrote:
>>>> Hello,
>>>> I've been testing this shared building roughly week now. My problem is
>>>> getting Mixxx (http://mixxx.org) compile on MinGW and linux so that's
>>>> why i'm interested in shared MXE.
>>>> I forked Shared MXE and I've added plenty missing packages and enabled
>>>> many packages to compile as shared DLL.
>>>> Now I've asking should I even try to make pull request or is it just
>>>> testing phase where ain't gonna get nothing in?
>>>
>>> That was a *big* patch set!
>>>
>>> I would recommend to separate adding new packages (chromaprint,
>>> libid3tag, taglib, rubberband, vamp-pluings-sdk) to another branch,
>>> that can be directly added to our current master branch.
>>>
>>> Regarding your question on how to contribute to @tonytheodore's repo,
>>> TBH I don't really know as I am not @tonytheodore. But if you really
>>> want to contribute, I'd say the following things:
>>>
>>> 1. merge the current master into that branch before the delta becomes too 
>>> big
>>> 2. make a pull req to Tony's repo if he agrees
>>>
>>> CC'ing the mailing list as I found out that this is not CC'd to it 
>>> currently.
>>>
>>> Timothy
>>
>> Thanks, I’ve had a quick look at 
>> https://github.com/illuusio/mxe/tree/shared-using-target and it seems that 
>> it should mostly be easy enough to merge. Some patches will be an issue 
>> though - take zlib-3-win32-tml.patch as an example, we can’t go hard-coding 
>> things like "#define ZLIB_DLL 1”.
>
> Actually that one can be forced out. It was just testing from another
> MinGW builds so it's not very clever patch.
>
>> I’ll make some time to do more testing, with the goal of getting the basic 
>> build rules into master fairly soon.
>
> There is lot of 'Works for me'-stuff in my repo. Hopefully patches are
> clean enough. There is lot of UPDATE stuff to work out as I'm little
> bit out of radar how that works..
>
> Thanks.
> Tuukka



reply via email to

[Prev in Thread] Current Thread [Next in Thread]