[PD] MinGW/Windows work session - tomorrow, Tuesday 5/18

[Hans-Christoph Steiner]

On May 26, 2009, at 2:37 PM, august wrote:

>>> this is where I got the glib and pkg-config
>>>
>>> 	http://www.gtk.org/download-windows.html
>>>
>>>
>>> I found that link  here:
>>>
>>> 	http://wiki.videolan.org/Win32CompileMSYSNew
>>>
>>>
>>> Might be other useful binaries there too.
>>
>> I started out making the Pd MiNGW build system like this, a wiki
>> documenting how to install a bunch of things found all over the  
>> net, but
>> it ended up being a ton of work every time I needed to revisit it  
>> (like
>> when I wanted to setup the build env on a new machine).  That's why I
>> started the 'sources' section in SVN with the build scripts.
>>
>> I am not saying that its the only way, I just think that if we are  
>> going
>> to use random binaries from the net, we need to have a good way to  
>> manage
>> them.  One way is to say that we only use binaries available from  
>> very
>> specific sources.
>>
>> Another possible solution is to check in the products of pkg-config  
>> into
>> the SVN.  Normally, this would be a bad idea, but since the idea  
>> here is
>> to have a standard distribution where it is always built the same  
>> way on
>> each machine, auto-configuration isn't needed.  If something isn't  
>> found
>> but autoconf, etc, then that's a problem that should be fixed before
>> building.  Otherwise, that will change the setup.
>>
>> .hc
>
> I know you have been doing this for a while and have your
> reasons,

Sorry, I'll shut up already.  I guess I am just tired of the  
annoyances of build systems.  I need to find a better outlet for  
venting :)

> but what I don't understand is if the "sources" are only for
> windows?  Or are they for mac as well?  I know they can't and  
> shouldn't
> be for linux as these are all or mostly apt-get'able.

The 'sources' tree is the package management for Windows since there  
is none that I know of.  Well, there is mingwPORTs, perhaps we should  
use that.  For Mac OS X the builds use Fink for the package  
management, then the GNU/Linux distros use their own.


> there are also a bunch of binaries we will need to build ffmpeg...such
> as msys-core, a new bash,  a new make.   Then for gmerlin_avdec we  
> will
> need a new autoconf and automake.

They just put out a final release candidate for MinGW 1.0.11, so it  
would be good to start with that, then see if it has the needed bash,  
autoconf, etc.  As for gmerlin_avdec, I think it might just be more  
managable to run the configure then check in the Makefiles and  
config.h.  There is only one CPU type current supported, 32-bit i386,  
and gmerlin_avdec doesn't depend on any Windows specifics, like XP vs  
Vista.

The ./configure stuff is all about detecting different setups and  
adjusting the build for them.  With package management, you kind of  
want the opposite: define a setup and throw errors if things are not  
following them.  For example, ./configure statements in packages end  
up looking like this to enforce that:

http://fink.cvs.sourceforge.net/fink/dists/10.4/unstable/main/finkinfo/graphics/ffmpeg.info
ConfigureParams: --mandir=%p/share/man --enable-shared --enable-gpl -- 
enable-pp --enable-swscaler --enable-pthreads --enable-x11grab -- 
enable-liba52 --enable-libamr-nb --enable-libfaac --enable-libfaad -- 
enable-libgsm --enable-libmp3lame --enable-libtheora --enable- 
libvorbis --enable-libx264 --enable-libxvid --disable-mmx --disable- 
iwmmxt (%m = powerpc) --enable-powerpc-perf (%m = i386) --disable- 
altivec


> I also notice that for x264 you
> disable asm code.....couldn't we just download a binary for yasm and
> enable that stuff?   Would be faster.

I just wanted to get it working, but anyone is welcome to improve  
things.  I tried yasm and it didn't seem that straightforward.

> with all of this stuff around in different spots, I don't think we are
> going to get a clean source compile on mingw for everything.    
> Wouldn't
> it be better to just make a downloadable package for mingw with all  
> the
> binaries?  I mean, isn't it a windows thing to package binaries  
> anyway?

> once we get all the binaries in place, it would be a simple wget and
> unzip command, no?


> forgive my ignorance ....'cause I'm sure you have your reasons...I  
> just
> don't smell what you are spraying just yet .    Is the idea with the
> "sources" just to get everything to compile from source?

That could work, but then upgrading one piece of source means making a  
whole new release of that package.  I manage enough binary releases as  
it is, I don't have time to do anymore.  As far as I am concerned, if  
someone wants to really own this, they can do it any way they want.   
But I don't have any time to spend on this, and it can take a ton of  
time, so while I am doing it, I'll stick to what I know works.

.hc


----------------------------------------------------------------------------

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie