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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
