August has ported gavl and gmerlin-avdecoder to MinGW, and August and
I have been cranking on trying to get the whole slew of libs building
for MinGW, so now we have a good reason to put some time into the
MinGW setup for Pd builds. readanysf~ uses them and with them works
really well. Gem is also going this route. It would make life much
easier if the Windows builds did too.
We are thinking it would be a lot more productive if we all work at
the same time on this stuff via IRC. Then we can ping each other with
questions, complain, swear at Windows, etc. You don't need to be a C
coder or an expert of any kind, just have an interest in getting
things building with MinGW. The more the merrier, join us in the
sharing the pain! :D
tomorrow (May 19, 2009-05-19) on IRC in #dataflow: irc://irc.freenode.net/dataflow
- 9.00 Pacific Time
- 11.00 Central Time
- 12.00 Eastern Time/PET
- 15.00 BRST/Sao Paulo
- 17.00 GMT/Zulu
- 18.00 Central European CET
- 19.00 EET/Istanbul/Cairo
- 20.00 MSD - Moscow Daylight Time
- 23.00 IST/Chennai
- 1.00 CST/Taipei (2009-05-20)
.hc
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
morning all,
as previously mentioned off-list, I'm likely to be a bit late in joining the misery, so I've gone and prepared a whole lot of buffered misery for y'all to play with (if time and interest permit) before I join in ;-) Circa 20MB of the aforementioned misery is available in concentrated form for a limited time only at:
http://odo.dwds.de/~moocow/moo.mingw-build.2009-05-17.tar.bz2
included are sources, patches, and scripts for building the following on mingw/msys:
flite : svn export, with patch & build script zlib : sources & build script expat : also libiconv : also also gettext : from the mingw site, with extra hacks (as patch) pkg-config : binary only, due to circular dependencies with glib libglib-2.x : sources & build script
... I've now successfully built all of these on my test machine (after killing the §"§&%$"§ webcam daemon... grr...), and included in the archive are build scripts a la 'build-libs-on-mingw.sh' for all of the libs (the only difference being an optional argument to force building even if the test-file is present). There's also a './build-all-moo.sh' to build everything in the archive in (I think!) an acceptable order.
feel free to commit any or all of this, with or without applied patches to the sources/ section and/or the main build-libs-on-mingw.sh script; otherwise I can do some or all of it when I show up (and reminisce about the bad old days of 2400 baud as I watch the IRC traffic crawl past during the commit ;-)
enjoy (ha!)
marmosets, Bryan
On 2009-05-18 21:39:58, Hans-Christoph Steiner hans@at.or.at appears to have written:
August has ported gavl and gmerlin-avdecoder to MinGW, and August and I have been cranking on trying to get the whole slew of libs building for MinGW, so now we have a good reason to put some time into the MinGW setup for Pd builds. readanysf~ uses them and with them works really well. Gem is also going this route. It would make life much easier if the Windows builds did too.
We are thinking it would be a lot more productive if we all work at the same time on this stuff via IRC. Then we can ping each other with questions, complain, swear at Windows, etc. You don't need to be a C coder or an expert of any kind, just have an interest in getting things building with MinGW. The more the merrier, join us in the sharing the pain! :D
tomorrow (May 19, 2009-05-19) on IRC in #dataflow: irc://irc.freenode.net/dataflow
- 9.00 Pacific Time
- 11.00 Central Time
- 12.00 Eastern Time/PET
- 15.00 BRST/Sao Paulo
- 17.00 GMT/Zulu
- 18.00 Central European CET
- 19.00 EET/Istanbul/Cairo
- 20.00 MSD - Moscow Daylight Time
- 23.00 IST/Chennai
- 1.00 CST/Taipei (2009-05-20)
.hc
So of your list there, we still have to handle glib and pkg-config.
As for binaries, there currently isn't really a way to manage them.
Right now, the setup uses binaries from the MinGW and MSYS installers,
then everything else is checked into SVN 'sources' and built from
source. In order to make this setup reproduceable, it needs to be
simple.
I think August got pkg-config going, was that a binary?
.hc
On May 18, 2009, at 5:01 PM, Bryan Jurish wrote:
morning all,
as previously mentioned off-list, I'm likely to be a bit late in
joining the misery, so I've gone and prepared a whole lot of buffered misery
for y'all to play with (if time and interest permit) before I join in ;-) Circa 20MB of the aforementioned misery is available in concentrated form for a limited time only at:http://odo.dwds.de/~moocow/moo.mingw-build.2009-05-17.tar.bz2
included are sources, patches, and scripts for building the
following on mingw/msys:flite : svn export, with patch & build script zlib : sources & build script expat : also libiconv : also also gettext : from the mingw site, with extra hacks (as patch) pkg-config : binary only, due to circular dependencies with glib libglib-2.x : sources & build script
... I've now successfully built all of these on my test machine (after killing the §"§&%$"§ webcam daemon... grr...), and included in the archive are build scripts a la 'build-libs-on-mingw.sh' for all of the libs (the only difference being an optional argument to force building even if the test-file is present). There's also a './build-all- moo.sh' to build everything in the archive in (I think!) an acceptable order.
feel free to commit any or all of this, with or without applied
patches to the sources/ section and/or the main build-libs-on-mingw.sh script; otherwise I can do some or all of it when I show up (and reminisce
about the bad old days of 2400 baud as I watch the IRC traffic crawl past during the commit ;-)enjoy (ha!)
marmosets, Bryan
On 2009-05-18 21:39:58, Hans-Christoph Steiner hans@at.or.at appears to have written:
August has ported gavl and gmerlin-avdecoder to MinGW, and August
and I have been cranking on trying to get the whole slew of libs building
for MinGW, so now we have a good reason to put some time into the MinGW setup for Pd builds. readanysf~ uses them and with them works really well. Gem is also going this route. It would make life much easier
if the Windows builds did too.We are thinking it would be a lot more productive if we all work at
the same time on this stuff via IRC. Then we can ping each other with questions, complain, swear at Windows, etc. You don't need to be a C coder or an expert of any kind, just have an interest in getting
things building with MinGW. The more the merrier, join us in the sharing
the pain! :Dtomorrow (May 19, 2009-05-19) on IRC in #dataflow: irc://irc.freenode.net/dataflow
- 9.00 Pacific Time
- 11.00 Central Time
- 12.00 Eastern Time/PET
- 15.00 BRST/Sao Paulo
- 17.00 GMT/Zulu
- 18.00 Central European CET
- 19.00 EET/Istanbul/Cairo
- 20.00 MSD - Moscow Daylight Time
- 23.00 IST/Chennai
- 1.00 CST/Taipei (2009-05-20)
.hc
-- Bryan Jurish "There is *always* one more
bug." jurish@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic
Entomology
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup
So of your list there, we still have to handle glib and pkg-config. As for binaries, there currently isn't really a way to manage them. Right now, the setup uses binaries from the MinGW and MSYS installers, then everything else is checked into SVN 'sources' and built from source. In order to make this setup reproduceable, it needs to be simple.
I think August got pkg-config going, was that a binary?
yeah, the only way to go is with binaries due to a circular dependency with glib and pkg-config.
On May 21, 2009, at 11:53 AM, august wrote:
So of your list there, we still have to handle glib and pkg- config. As for binaries, there currently isn't really a way to manage them.
Right now, the setup uses binaries from the MinGW and MSYS installers, then everything else is checked into SVN 'sources' and built from
source. In order to make this setup reproduceable, it needs to be simple.I think August got pkg-config going, was that a binary?
yeah, the only way to go is with binaries due to a circular dependency with glib and pkg-config.
Which binary did you use? Is there an 'official' MinGW one?
.hc
kill your television
moin all,
On 2009-05-21 18:10:35, Hans-Christoph Steiner hans@at.or.at appears to have written:
On May 21, 2009, at 11:53 AM, august wrote:
So of your list there, we still have to handle glib and pkg-config. As for binaries, there currently isn't really a way to manage them. Right now, the setup uses binaries from the MinGW and MSYS installers, then everything else is checked into SVN 'sources' and built from source. In order to make this setup reproduceable, it needs to be simple.
I think August got pkg-config going, was that a binary?
yeah, the only way to go is with binaries due to a circular dependency with glib and pkg-config.
after a brief look at glib's configure.ac, it looks to me like the glib -> pkg-config "dependency" isn't really one, and could be fixed by some judicious use of 'dnl' (m4 comment-ization) in glib/configure.ac.
Which binary did you use? Is there an 'official' MinGW one?
I second the question: august?
for my own part, I didn't find a pkg-config binary from either mingw or gnuwin, so i used the binaries referenced on gtk.org:
http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config-0.23-2...
which worked to build glib, but after 'svn up'-ing pure-data/sources, a whole bunch of libs have been complaining, and I'm getting pkg-config crashes during build-libs-on-mingw.sh (i can attach a log, but it's huge and i haven't really identified the problem yet). so i think a better way to go would be:
- comment out the AC_PROG(pkg-config) in glib/configure.ac (or
configure.in, I forget which convention glib uses)
- tweak the libpcre clauses so that they don't call pkg-config (afaict,
the GRegex/PCRE stuff is the only place glib actually calls pkg-config),
re-generate the glib autotools stuff (e.g. autoreconf)
use the --with-local-pcre or whatever option to glib ./configure and
it ought to build
... no time for this atm, especially since these other libs are giving me grief and annoying segfault popups ... grr
Strangely, http://pkgconfig.freedesktop.org/wiki/ (the official pkg-config home) reports:
"A copy of glib 1.2.8 is shipped together with pkg-config and this is sufficient for pkg-config to compile and work properly"
huh...
marmosets, Bryan
after a brief look at glib's configure.ac, it looks to me like the glib -> pkg-config "dependency" isn't really one, and could be fixed by some judicious use of 'dnl' (m4 comment-ization) in glib/configure.ac.
Which binary did you use? Is there an 'official' MinGW one?
I second the question: august?
for my own part, I didn't find a pkg-config binary from either mingw or gnuwin, so i used the binaries referenced on gtk.org:
http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config-0.23-2...
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.
-a.
On May 26, 2009, at 12:30 PM, august wrote:
after a brief look at glib's configure.ac, it looks to me like the
glib -> pkg-config "dependency" isn't really one, and could be fixed by
some judicious use of 'dnl' (m4 comment-ization) in glib/configure.ac.Which binary did you use? Is there an 'official' MinGW one?
I second the question: august?
for my own part, I didn't find a pkg-config binary from either
mingw or gnuwin, so i used the binaries referenced on gtk.org:http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config-0.23-2...
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
Mistrust authority - promote decentralization. - the hacker ethic
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, 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.
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. 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.
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?
thanks for your patience -august.
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
-
august -
Bryan Jurish -
Hans-Christoph Steiner