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/graph... 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