I would like to participate in the Google Summer of Code improving
GStreamer on Windows. GStreamer is well known multimedia framework in the GNU/Linux world, but we cannot say the same thing for Windows and Mac. Many developpers are afraid to use GStreamer on these platforms for a simple reason: the GStreamer team doesn't provide updated binaries and it's quite difficult to compile your own GStreamer binaries (at least for Windows). My project (www.ylatuya.es) uses GStreamer on Linux, and I wanted to port it to Windows and Mac. On the Windows side I had to face many problems... The first one, as I told before, is that there is no GStreamer binary packages for Windows. So I started thinking about compiling GStreamer by own and then I faced the other big problem: creating a build environment to compile all the GStreamer plugins, including those that has external dependencies. That's why I decided to start a new project, GStreamer Winbuilds (http://www.gstreamer-winbuild.ylatuya.es), together with Andres Colubri, to provide an installer with functional and updated GStreamer binary packages, and a build environment for GStreamer. This project is actually based on OABuild because OAH wasn't ready yet. But the main question is always the same.. Why do we need OABuild or OAH? Because getting a complete build environment on Windows is quite difficult. My proposal for the GSoC to improve GStreamer in Windows is based on this points: *Create a script to automatize the creation of a build environment to compile GStreamer on Windows. The goal of this script is to fetch all the external dependencies that provide pre-compiled binaries and developers files (as for GLib, pango, speex, etc...) or build those that doesn't. This script will also fecth and patch the GStreamer sources (some plugins needs small fixes to compile under MSVC, for example) *Migrate all the existing Visual Studio projects to codeblocks which is Free Software and can be used with many C/C++ compilers (GCC, MSVC, Borland, etc..) *Finish the work started with GStreamer WinBuild by adding all the remaining plugins and create an installer with the whole GStreamer's plugins set. I hope you will consider my proposal!!! Regards, Andoni Morales ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Andoni Morales wrote:
> I would like to participate in the Google Summer of Code improving > GStreamer on Windows. > > GStreamer is well known multimedia framework in the GNU/Linux world, > but we cannot say the same thing for Windows and Mac. Many developpers > are afraid to use GStreamer on these platforms for a simple reason: > the GStreamer team doesn't provide updated binaries and it's quite > difficult to compile your own GStreamer binaries (at least for > Windows). > My project (www.ylatuya.es) uses GStreamer on Linux, and I wanted to > port it to Windows and Mac. On the Windows side I had to face many > problems... The first one, as I told before, is that there is no > GStreamer binary packages for Windows. So I started thinking about > compiling GStreamer by own and then I faced the other big problem: > creating a build environment to compile all the GStreamer plugins, > including those that has external dependencies. > That's why I decided to start a new project, GStreamer Winbuilds > (http://www.gstreamer-winbuild.ylatuya.es), together with Andres > Colubri, to provide an installer with functional and updated > GStreamer binary packages, and a build environment for GStreamer. This > project is actually based on OABuild because OAH wasn't ready yet. But > the main question is always the same.. Why do we need OABuild or OAH? > Because getting a complete build environment on Windows is quite > difficult. > > My proposal for the GSoC to improve GStreamer in Windows is based on > this points: > > *Create a script to automatize the creation of a build environment > to compile GStreamer on Windows. The goal of this script is to fetch > all the external dependencies that provide pre-compiled binaries and > developers files (as for GLib, pango, speex, etc...) or build those > that doesn't. This script will also fecth and patch the GStreamer > sources (some plugins needs small fixes to compile under MSVC, for > example) > *Migrate all the existing Visual Studio projects to codeblocks > which is Free Software and can be used with many C/C++ compilers (GCC, > MSVC, Borland, etc..) > *Finish the work started with GStreamer WinBuild by adding all the > remaining plugins and create an installer with the whole GStreamer's > plugins set. > > I hope you will consider my proposal!!! at the same time we also start to push gstreamer into fedora's mingw packages: http://fedoraproject.org/wiki/MinGW so we can build everything on linux without windows with the same tools (ie. compiler, linker etc) as the linux version. the big problem that we've to package all required deps too which required a huge work since there are dozens of libs which have to repackage again. any helps are welcome:-) -- Levente "Si vis pacem para bellum!" ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Andoni Morales
Andoni Morales schrieb:
> I would like to participate in the Google Summer of Code improving > GStreamer on Windows. > > GStreamer is well known multimedia framework in the GNU/Linux world, > but we cannot say the same thing for Windows and Mac. Many developpers > are afraid to use GStreamer on these platforms for a simple reason: > the GStreamer team doesn't provide updated binaries and it's quite > difficult to compile your own GStreamer binaries (at least for > Windows). > My project (www.ylatuya.es) uses GStreamer on Linux, and I wanted to > port it to Windows and Mac. On the Windows side I had to face many > problems... The first one, as I told before, is that there is no > GStreamer binary packages for Windows. So I started thinking about > compiling GStreamer by own and then I faced the other big problem: > creating a build environment to compile all the GStreamer plugins, > including those that has external dependencies. > That's why I decided to start a new project, GStreamer Winbuilds > (http://www.gstreamer-winbuild.ylatuya.es), together with Andres > Colubri, to provide an installer with functional and updated > GStreamer binary packages, and a build environment for GStreamer. This > project is actually based on OABuild because OAH wasn't ready yet. But > the main question is always the same.. Why do we need OABuild or OAH? > Because getting a complete build environment on Windows is quite > difficult. > > don't include Mac in the headline, if you don't plan to cover it :) > My proposal for the GSoC to improve GStreamer in Windows is based on > this points: > > *Create a script to automatize the creation of a build environment > to compile GStreamer on Windows. The goal of this script is to fetch > all the external dependencies that provide pre-compiled binaries and > developers files (as for GLib, pango, speex, etc...) or build those > that doesn't. This script will also fecth and patch the GStreamer > sources (some plugins needs small fixes to compile under MSVC, for > example) > part of the build procedure should be very intermediate only. > *Migrate all the existing Visual Studio projects to codeblocks > which is Free Software and can be used with many C/C++ compilers (GCC, > MSVC, Borland, etc..) > please add a link to codeblocks. > *Finish the work started with GStreamer WinBuild by adding all the > remaining plugins and create an installer with the whole GStreamer's > plugins set. > > I hope you will consider my proposal!!! > > Regards, > Andoni Morales > > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
> A few comments:
> don't include Mac in the headline, if you don't plan to cover it :) > Andrés is actually working on the Mac installer and it would be nice to include it in the GSoC project. The problem with macports and GStreamer is that some plugins depends on GTK, which adds an important overhead when you have to package everything. Our idea is to remove these plugins to reduce the size of the final package. >> My proposal for the GSoC to improve GStreamer in Windows is based on >> this points: >> >> *Create a script to automatize the creation of a build environment >> to compile GStreamer on Windows. The goal of this script is to fetch >> all the external dependencies that provide pre-compiled binaries and >> developers files (as for GLib, pango, speex, etc...) or build those >> that doesn't. This script will also fecth and patch the GStreamer >> sources (some plugins needs small fixes to compile under MSVC, for >> example) >> > please file bug for those and attach patches. Maintaining patches as > part of the build procedure should be very intermediate only. >> *Migrate all the existing Visual Studio projects to codeblocks >> which is Free Software and can be used with many C/C++ compilers (GCC, >> MSVC, Borland, etc..) >> > please add a link to codeblocks. The Code::Blocks home page is: http://www.codeblocks.org/ Julien Isorce is also using this IDE for gst-plugins-gl Andoni ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Farkas Levente
2009/3/25 Farkas Levente <[hidden email]>:
> Andoni Morales wrote: >> I would like to participate in the Google Summer of Code improving >> GStreamer on Windows. >> >> GStreamer is well known multimedia framework in the GNU/Linux world, >> but we cannot say the same thing for Windows and Mac. Many developpers >> are afraid to use GStreamer on these platforms for a simple reason: >> the GStreamer team doesn't provide updated binaries and it's quite >> difficult to compile your own GStreamer binaries (at least for >> Windows). >> My project (www.ylatuya.es) uses GStreamer on Linux, and I wanted to >> port it to Windows and Mac. On the Windows side I had to face many >> problems... The first one, as I told before, is that there is no >> GStreamer binary packages for Windows. So I started thinking about >> compiling GStreamer by own and then I faced the other big problem: >> creating a build environment to compile all the GStreamer plugins, >> including those that has external dependencies. >> That's why I decided to start a new project, GStreamer Winbuilds >> (http://www.gstreamer-winbuild.ylatuya.es), together with Andres >> Colubri, to provide an installer with functional and updated >> GStreamer binary packages, and a build environment for GStreamer. This >> project is actually based on OABuild because OAH wasn't ready yet. But >> the main question is always the same.. Why do we need OABuild or OAH? >> Because getting a complete build environment on Windows is quite >> difficult. >> >> My proposal for the GSoC to improve GStreamer in Windows is based on >> this points: >> >> *Create a script to automatize the creation of a build environment >> to compile GStreamer on Windows. The goal of this script is to fetch >> all the external dependencies that provide pre-compiled binaries and >> developers files (as for GLib, pango, speex, etc...) or build those >> that doesn't. This script will also fecth and patch the GStreamer >> sources (some plugins needs small fixes to compile under MSVC, for >> example) >> *Migrate all the existing Visual Studio projects to codeblocks >> which is Free Software and can be used with many C/C++ compilers (GCC, >> MSVC, Borland, etc..) >> *Finish the work started with GStreamer WinBuild by adding all the >> remaining plugins and create an installer with the whole GStreamer's >> plugins set. >> >> I hope you will consider my proposal!!! > > at the same time we also start to push gstreamer into fedora's mingw > packages: > http://fedoraproject.org/wiki/MinGW > so we can build everything on linux without windows with the same tools > (ie. compiler, linker etc) as the linux version. > the big problem that we've to package all required deps too which > required a huge work since there are dozens of libs which have to > repackage again. This is the most annoying part when you try to build GStreamer on Windows, and that's why I would like to automatize this process. > any helps are welcome:-) > > -- > Levente "Si vis pacem para bellum!" > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Andoni Morales
>> please add a link to codeblocks.
> > The Code::Blocks home page is: http://www.codeblocks.org/ > Julien Isorce is also using this IDE for gst-plugins-gl > I forgot to mention that Code::Blocks can also be used to compile GStreamer in Mac OS X and to cross-compile GStreamer in Linux Andoni ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Hi,
2009/3/25 Andoni Morales <[hidden email]>
I like codeblocks but the best choice is to use CMake. ( http://www.cmake.org/ ) It's the most easiest, usable, viable, extensible etc... build system known. Qt and KDE are using it now. CMake can generate codeblocks projects and more. CMake is cross platform. It can generate those things: Unix Makefiles = Generates standard UNIX makefiles. CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project files. KDevelop3 = Generates KDevelop 3 project files. KDevelop3 - Unix Makefiles = Generates KDevelop 3 project files. Borland Makefiles = Generates Borland makefiles. MSYS Makefiles = Generates MSYS makefiles. MinGW Makefiles = Generates a make file for use with mingw32-make. NMake Makefiles = Generates NMake makefiles. Unix Makefiles = Generates standard UNIX makefiles. Visual Studio 6 = Generates Visual Studio 6 project files. Visual Studio 7 = Generates Visual Studio .NET 2002 project files. Visual Studio 7 .NET 2003 = Generates Visual Studio .NET 2003 projectfiles. Visual Studio 8 2005 = Generates Visual Studio .NET 2005 project files. Visual Studio 8 2005 Win64 = Generates Visual Studio .NET 2005 Win64 project files. Visual Studio 9 2008 = Generates Visual Studio 9 2008 project files. Visual Studio 9 2008 Win64 = Generates Visual Studio 9 2008 Win64 project files. Watcom WMake = Generates Watcom WMake makefiles. CodeBlocks - MinGW Makefiles= Generates CodeBlocks project files. CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. Eclipse CDT4 - MinGW Makefiles = Generates Eclipse CDT 4.0 project files. Eclipse CDT4 - NMake Makefiles = Generates Eclipse CDT 4.0 project files. Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project files. CMake can also generate XCode projects, and "darwin makefiles" but I have no Mac machine to copy/past the output of cmake --help. I am also using it in gst-plugins-gl. So I can help. Moreover, CMake can generate installers Windows is so horrible when a project is big and has a lot of dependencies. (as a lot of projects are). Every software on windows comes with their own glib/qt/png/etc... dlls. It's just like anarchy. MSYS thought to be the solution of this but still unix mind in this. Windows just need a packaging tool ( like apt) and "depo" servers. And because it's on windows, this tool would be GUI only . We could start a such project. Anyway it's an other subject. CMake power ! gl & hf Julien
------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
2009/3/25 Julien Isorce <[hidden email]> Hi, So CMake seems to be the best choice!
Deploying a Free Software app on Windows is worst than hell. As this packaging tool doesn't exist yet, the best approach is to use a script to fetch all the dependencies. Andoni
------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Administrator
|
In reply to this post by Julien Isorce
On Wed, 2009-03-25 at 17:55 +0100, Julien Isorce wrote:
> Hi, > > 2009/3/25 Andoni Morales <[hidden email]> > >> please add a link to codeblocks. > > > > The Code::Blocks home page is: http://www.codeblocks.org/ > > Julien Isorce is also using this IDE for gst-plugins-gl > > > > I forgot to mention that Code::Blocks can also be used to > compile > GStreamer in Mac OS X and to cross-compile GStreamer in Linux > > I like codeblocks but the best choice is to use CMake. > ( http://www.cmake.org/ ) > It's the most easiest, usable, viable, extensible etc... build system > known. > Qt and KDE are using it now. > CMake can generate codeblocks projects and more. > > CMake is cross platform. It can generate those things: > > Unix Makefiles = Generates standard UNIX makefiles. > CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. > Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project > files. > KDevelop3 = Generates KDevelop 3 project files. > KDevelop3 - Unix Makefiles = Generates KDevelop 3 project files. > Borland Makefiles = Generates Borland makefiles. > MSYS Makefiles = Generates MSYS makefiles. > MinGW Makefiles = Generates a make file for use with mingw32-make. > NMake Makefiles = Generates NMake makefiles. > Unix Makefiles = Generates standard UNIX makefiles. > Visual Studio 6 = Generates Visual Studio 6 project files. > Visual Studio 7 = Generates Visual Studio .NET 2002 project files. > Visual Studio 7 .NET 2003 = Generates Visual Studio .NET 2003 > projectfiles. > Visual Studio 8 2005 = Generates Visual Studio .NET 2005 project > files. > Visual Studio 8 2005 Win64 = Generates Visual Studio .NET 2005 Win64 > project files. > Visual Studio 9 2008 = Generates Visual Studio 9 2008 project files. > Visual Studio 9 2008 Win64 = Generates Visual Studio 9 2008 Win64 > project files. > Watcom WMake = Generates Watcom WMake makefiles. > CodeBlocks - MinGW Makefiles= Generates CodeBlocks project files. > CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. > Eclipse CDT4 - MinGW Makefiles = Generates Eclipse CDT 4.0 project > files. > Eclipse CDT4 - NMake Makefiles = Generates Eclipse CDT 4.0 project > files. > Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project > files. > > CMake can also generate XCode projects, and "darwin makefiles" but I > have no Mac machine to copy/past the output of cmake --help. > > I am also using it in gst-plugins-gl. So I can help. > > Moreover, CMake can generate installers Some questions that come to mind: * How easy is it to teach it new build systems (S60 and Android come to mind here). That includes Makfile, auto-generated files, etc... If it can... this would ease the portability work of GStreamer (and plugins) a *LOT*. * What are the compile-time dependencies ? How easy/hard would it be to use it in a cross-compile setup ? Can it run in esoteric setups ? If we can gain new systems but lose old systems (on which auto* works perfectly well due to only requiring a shell) it's gonna be a definite blocker. CMake looks *very* tempting (he who has read the libtool code with love throws the first stone), but we need to make sure we're not losing anything if we switch. Edward > > Windows is so horrible when a project is big and has a lot of > dependencies. (as a lot of projects are). > Every software on windows comes with their own glib/qt/png/etc... > dlls. It's just like anarchy. > MSYS thought to be the solution of this but still unix mind in this. > Windows just need a packaging tool ( like apt) and "depo" servers. And > because it's on windows, this tool would be GUI only . > We could start a such project. > Anyway it's an other subject. > > CMake power ! > > gl & hf > > Julien > > > > Andoni > > ------------------------------------------------------------------------------ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Andoni Morales
Andoni Morales schrieb:
>> A few comments: >> don't include Mac in the headline, if you don't plan to cover it :) >> > > Andrés is actually working on the Mac installer and it would be nice > to include it in the GSoC project. The problem with macports and > GStreamer is that some plugins depends on GTK, which adds an important > overhead when you have to package everything. Our idea is to remove > these plugins to reduce the size of the final package. There are no *plugins* that depends on gtk. gtk is only used in tests/examples. > >>> My proposal for the GSoC to improve GStreamer in Windows is based on >>> this points: >>> >>> *Create a script to automatize the creation of a build environment >>> to compile GStreamer on Windows. The goal of this script is to fetch >>> all the external dependencies that provide pre-compiled binaries and >>> developers files (as for GLib, pango, speex, etc...) or build those >>> that doesn't. This script will also fecth and patch the GStreamer >>> sources (some plugins needs small fixes to compile under MSVC, for >>> example) >>> >> please file bug for those and attach patches. Maintaining patches as >> part of the build procedure should be very intermediate only. >>> *Migrate all the existing Visual Studio projects to codeblocks >>> which is Free Software and can be used with many C/C++ compilers (GCC, >>> MSVC, Borland, etc..) >>> >> please add a link to codeblocks. > > The Code::Blocks home page is: http://www.codeblocks.org/ > Julien Isorce is also using this IDE for gst-plugins-gl looks nice. Stefan > > > Andoni > > ------------------------------------------------------------------------------ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
2009/3/25 Stefan Kost <[hidden email]>:
> Andoni Morales schrieb: >>> A few comments: >>> don't include Mac in the headline, if you don't plan to cover it :) >>> >> >> Andrés is actually working on the Mac installer and it would be nice >> to include it in the GSoC project. The problem with macports and >> GStreamer is that some plugins depends on GTK, which adds an important >> overhead when you have to package everything. Our idea is to remove >> these plugins to reduce the size of the final package. > > There are no *plugins* that depends on gtk. gtk is only used in tests/examples. Not directly, but in macports gst-plugins-bad depends on gnomevfs, which depends on gconf, and this last depends on gtk. So, by removing the gnomevfs dependency from the gst-plugins-bad Portfiles, you are reducing the dependencies tree. > >> >>>> My proposal for the GSoC to improve GStreamer in Windows is based on >>>> this points: >>>> >>>> *Create a script to automatize the creation of a build environment >>>> to compile GStreamer on Windows. The goal of this script is to fetch >>>> all the external dependencies that provide pre-compiled binaries and >>>> developers files (as for GLib, pango, speex, etc...) or build those >>>> that doesn't. This script will also fecth and patch the GStreamer >>>> sources (some plugins needs small fixes to compile under MSVC, for >>>> example) >>>> >>> please file bug for those and attach patches. Maintaining patches as >>> part of the build procedure should be very intermediate only. >>>> *Migrate all the existing Visual Studio projects to codeblocks >>>> which is Free Software and can be used with many C/C++ compilers (GCC, >>>> MSVC, Borland, etc..) >>>> >>> please add a link to codeblocks. >> >> The Code::Blocks home page is: http://www.codeblocks.org/ >> Julien Isorce is also using this IDE for gst-plugins-gl > > looks nice. > > Stefan >> >> >> Andoni >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Edward Hervey
2009/3/25 Edward Hervey <[hidden email]>:
> On Wed, 2009-03-25 at 17:55 +0100, Julien Isorce wrote: >> Hi, >> >> 2009/3/25 Andoni Morales <[hidden email]> >> >> please add a link to codeblocks. >> > >> > The Code::Blocks home page is: http://www.codeblocks.org/ >> > Julien Isorce is also using this IDE for gst-plugins-gl >> > >> >> I forgot to mention that Code::Blocks can also be used to >> compile >> GStreamer in Mac OS X and to cross-compile GStreamer in Linux >> >> I like codeblocks but the best choice is to use CMake. >> ( http://www.cmake.org/ ) >> It's the most easiest, usable, viable, extensible etc... build system >> known. >> Qt and KDE are using it now. >> CMake can generate codeblocks projects and more. >> >> CMake is cross platform. It can generate those things: >> >> Unix Makefiles = Generates standard UNIX makefiles. >> CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. >> Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project >> files. >> KDevelop3 = Generates KDevelop 3 project files. >> KDevelop3 - Unix Makefiles = Generates KDevelop 3 project files. >> Borland Makefiles = Generates Borland makefiles. >> MSYS Makefiles = Generates MSYS makefiles. >> MinGW Makefiles = Generates a make file for use with mingw32-make. >> NMake Makefiles = Generates NMake makefiles. >> Unix Makefiles = Generates standard UNIX makefiles. >> Visual Studio 6 = Generates Visual Studio 6 project files. >> Visual Studio 7 = Generates Visual Studio .NET 2002 project files. >> Visual Studio 7 .NET 2003 = Generates Visual Studio .NET 2003 >> projectfiles. >> Visual Studio 8 2005 = Generates Visual Studio .NET 2005 project >> files. >> Visual Studio 8 2005 Win64 = Generates Visual Studio .NET 2005 Win64 >> project files. >> Visual Studio 9 2008 = Generates Visual Studio 9 2008 project files. >> Visual Studio 9 2008 Win64 = Generates Visual Studio 9 2008 Win64 >> project files. >> Watcom WMake = Generates Watcom WMake makefiles. >> CodeBlocks - MinGW Makefiles= Generates CodeBlocks project files. >> CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. >> Eclipse CDT4 - MinGW Makefiles = Generates Eclipse CDT 4.0 project >> files. >> Eclipse CDT4 - NMake Makefiles = Generates Eclipse CDT 4.0 project >> files. >> Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project >> files. >> >> CMake can also generate XCode projects, and "darwin makefiles" but I >> have no Mac machine to copy/past the output of cmake --help. >> >> I am also using it in gst-plugins-gl. So I can help. >> >> Moreover, CMake can generate installers > > Some questions that come to mind: > * How easy is it to teach it new build systems (S60 and Android come > to mind here). That includes Makfile, auto-generated files, etc... If it > can... this would ease the portability work of GStreamer (and plugins) a > *LOT*. > * What are the compile-time dependencies ? How easy/hard would it be > to use it in a cross-compile setup ? Can it run in esoteric setups ? If > we can gain new systems but lose old systems (on which auto* works > perfectly well due to only requiring a shell) it's gonna be a definite > blocker. As far as i know, CMake is similar to Autotools, in the sense that you just need it to process the configuration files. Then you can choose between creating standard makefiles if you want to use it in a shell environment, or creating Visual Studio projects if you want to use an IDE. > > CMake looks *very* tempting (he who has read the libtool code with > love throws the first stone), but we need to make sure we're not losing > anything if we switch. > > Edward > >> >> Windows is so horrible when a project is big and has a lot of >> dependencies. (as a lot of projects are). >> Every software on windows comes with their own glib/qt/png/etc... >> dlls. It's just like anarchy. >> MSYS thought to be the solution of this but still unix mind in this. >> Windows just need a packaging tool ( like apt) and "depo" servers. And >> because it's on windows, this tool would be GUI only . >> We could start a such project. >> Anyway it's an other subject. >> >> CMake power ! >> >> gl & hf >> >> Julien >> >> >> >> Andoni >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Andoni Morales
Andoni Morales schrieb:
> 2009/3/25 Stefan Kost <[hidden email]>: >> Andoni Morales schrieb: >>>> A few comments: >>>> don't include Mac in the headline, if you don't plan to cover it :) >>>> >>> Andrés is actually working on the Mac installer and it would be nice >>> to include it in the GSoC project. The problem with macports and >>> GStreamer is that some plugins depends on GTK, which adds an important >>> overhead when you have to package everything. Our idea is to remove >>> these plugins to reduce the size of the final package. >> There are no *plugins* that depends on gtk. gtk is only used in tests/examples. > > Not directly, but in macports gst-plugins-bad depends on gnomevfs, > which depends on gconf, and this last depends on gtk. So, by removing > the gnomevfs dependency from the gst-plugins-bad Portfiles, you are > reducing the dependencies tree. gnomevfs is in base. and a gconf package should not hard-depend on gtk. But anyway gnomevfs plugin is kind of superseeded by the gio one (almost) so thats okay. Stefan ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Andoni Morales
Andoni Morales schrieb:
> 2009/3/25 Edward Hervey <[hidden email]>: >> On Wed, 2009-03-25 at 17:55 +0100, Julien Isorce wrote: >>> Hi, >>> >>> 2009/3/25 Andoni Morales <[hidden email]> >>> >> please add a link to codeblocks. >>> > >>> > The Code::Blocks home page is: http://www.codeblocks.org/ >>> > Julien Isorce is also using this IDE for gst-plugins-gl >>> > >>> >>> I forgot to mention that Code::Blocks can also be used to >>> compile >>> GStreamer in Mac OS X and to cross-compile GStreamer in Linux >>> >>> I like codeblocks but the best choice is to use CMake. >>> ( http://www.cmake.org/ ) >>> It's the most easiest, usable, viable, extensible etc... build system >>> known. >>> Qt and KDE are using it now. >>> CMake can generate codeblocks projects and more. >>> >>> CMake is cross platform. It can generate those things: >>> >>> Unix Makefiles = Generates standard UNIX makefiles. >>> CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. >>> Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project >>> files. >>> KDevelop3 = Generates KDevelop 3 project files. >>> KDevelop3 - Unix Makefiles = Generates KDevelop 3 project files. >>> Borland Makefiles = Generates Borland makefiles. >>> MSYS Makefiles = Generates MSYS makefiles. >>> MinGW Makefiles = Generates a make file for use with mingw32-make. >>> NMake Makefiles = Generates NMake makefiles. >>> Unix Makefiles = Generates standard UNIX makefiles. >>> Visual Studio 6 = Generates Visual Studio 6 project files. >>> Visual Studio 7 = Generates Visual Studio .NET 2002 project files. >>> Visual Studio 7 .NET 2003 = Generates Visual Studio .NET 2003 >>> projectfiles. >>> Visual Studio 8 2005 = Generates Visual Studio .NET 2005 project >>> files. >>> Visual Studio 8 2005 Win64 = Generates Visual Studio .NET 2005 Win64 >>> project files. >>> Visual Studio 9 2008 = Generates Visual Studio 9 2008 project files. >>> Visual Studio 9 2008 Win64 = Generates Visual Studio 9 2008 Win64 >>> project files. >>> Watcom WMake = Generates Watcom WMake makefiles. >>> CodeBlocks - MinGW Makefiles= Generates CodeBlocks project files. >>> CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. >>> Eclipse CDT4 - MinGW Makefiles = Generates Eclipse CDT 4.0 project >>> files. >>> Eclipse CDT4 - NMake Makefiles = Generates Eclipse CDT 4.0 project >>> files. >>> Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project >>> files. >>> >>> CMake can also generate XCode projects, and "darwin makefiles" but I >>> have no Mac machine to copy/past the output of cmake --help. >>> >>> I am also using it in gst-plugins-gl. So I can help. >>> >>> Moreover, CMake can generate installers >> Some questions that come to mind: >> * How easy is it to teach it new build systems (S60 and Android come >> to mind here). That includes Makfile, auto-generated files, etc... If it >> can... this would ease the portability work of GStreamer (and plugins) a >> *LOT*. >> * What are the compile-time dependencies ? How easy/hard would it be >> to use it in a cross-compile setup ? Can it run in esoteric setups ? If >> we can gain new systems but lose old systems (on which auto* works >> perfectly well due to only requiring a shell) it's gonna be a definite >> blocker. > > As far as i know, CMake is similar to Autotools, in the sense that > you just need it to process the configuration files. Then you can > choose between creating standard makefiles if you want to use it in a > shell environment, or creating Visual Studio projects if you want to > use an IDE. > >> CMake looks *very* tempting (he who has read the libtool code with >> love throws the first stone), but we need to make sure we're not losing >> anything if we switch. >> >> Edward >> If the CMake people would only have picked a decent syntax for the CMakelist.txt files .... Stefan ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Andoni Morales
Andoni Morales wrote:
>> A few comments: >> don't include Mac in the headline, if you don't plan to cover it :) > > Andrés is actually working on the Mac installer and it would be nice > to include it in the GSoC project. The problem with macports and > GStreamer is that some plugins depends on GTK, which adds an important > overhead when you have to package everything. Our idea is to remove > these plugins to reduce the size of the final package. I prepared a Mac installer using the latest portfiles from macports (with some dependencies removed, as Andoni mentioned above). The actual size of the installer is quite reasonable (45 Mb for the disk image file), and includes a quite large number of plugins (among gst-plugins good, bad, ugly and ffmpeg). Similarly to what we did with the windows installer, the mac installer encapsulates all the gst plugins modules into a single package. With this installer I'm trying to follow the standard directory structure in OSX. However, I'm not very knowledgeable in this regard, so comments and suggestions for improvements are welcomed. The installer currently copies the gstreamer files into /System/Library/GStreamer, and within this folder you just have /bin, /lib, /include, /lib/gstreamer-0.1.0, etc., in other words exactly the same tree structure that macports creates by default inside /opt/local. The installer also sets the environmental variables DYLD_LIBRARY_PATH and GST_PLUGIN_PATH to /System/Library/GStreamer/lib and /System/Library/GStreamer/lib/gstreamer-0.10, respectively. This is done in the post-installation stage, by adding the appropriate setenv lines to the system file /etc/launchd.conf (I followed the rationale explained in this article: http://www.digitaledgesw.com/node/31). But maybe this should be done differently. For those interested in giving this installer a try, here is the link from where you can download it: http://users.design.ucla.edu/~acolubri/test/gstreamer/macosx/GStreamer-MacBuild-0.10.1-Leopard.dmg ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
In reply to this post by Stefan Sauer
On Wed, Mar 25, 2009 at 9:48 PM, Stefan Kost <[hidden email]> wrote:
> Andoni Morales schrieb: >> 2009/3/25 Edward Hervey <[hidden email]>: >>> On Wed, 2009-03-25 at 17:55 +0100, Julien Isorce wrote: >>>> Hi, >>>> >>>> 2009/3/25 Andoni Morales <[hidden email]> >>>> >> please add a link to codeblocks. >>>> > >>>> > The Code::Blocks home page is: http://www.codeblocks.org/ >>>> > Julien Isorce is also using this IDE for gst-plugins-gl >>>> > >>>> >>>> I forgot to mention that Code::Blocks can also be used to >>>> compile >>>> GStreamer in Mac OS X and to cross-compile GStreamer in Linux >>>> >>>> I like codeblocks but the best choice is to use CMake. >>>> ( http://www.cmake.org/ ) >>>> It's the most easiest, usable, viable, extensible etc... build system >>>> known. >>>> Qt and KDE are using it now. >>>> CMake can generate codeblocks projects and more. >>>> >>>> CMake is cross platform. It can generate those things: >>>> >>>> Unix Makefiles = Generates standard UNIX makefiles. >>>> CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. >>>> Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project >>>> files. >>>> KDevelop3 = Generates KDevelop 3 project files. >>>> KDevelop3 - Unix Makefiles = Generates KDevelop 3 project files. >>>> Borland Makefiles = Generates Borland makefiles. >>>> MSYS Makefiles = Generates MSYS makefiles. >>>> MinGW Makefiles = Generates a make file for use with mingw32-make. >>>> NMake Makefiles = Generates NMake makefiles. >>>> Unix Makefiles = Generates standard UNIX makefiles. >>>> Visual Studio 6 = Generates Visual Studio 6 project files. >>>> Visual Studio 7 = Generates Visual Studio .NET 2002 project files. >>>> Visual Studio 7 .NET 2003 = Generates Visual Studio .NET 2003 >>>> projectfiles. >>>> Visual Studio 8 2005 = Generates Visual Studio .NET 2005 project >>>> files. >>>> Visual Studio 8 2005 Win64 = Generates Visual Studio .NET 2005 Win64 >>>> project files. >>>> Visual Studio 9 2008 = Generates Visual Studio 9 2008 project files. >>>> Visual Studio 9 2008 Win64 = Generates Visual Studio 9 2008 Win64 >>>> project files. >>>> Watcom WMake = Generates Watcom WMake makefiles. >>>> CodeBlocks - MinGW Makefiles= Generates CodeBlocks project files. >>>> CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. >>>> Eclipse CDT4 - MinGW Makefiles = Generates Eclipse CDT 4.0 project >>>> files. >>>> Eclipse CDT4 - NMake Makefiles = Generates Eclipse CDT 4.0 project >>>> files. >>>> Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project >>>> files. >>>> >>>> CMake can also generate XCode projects, and "darwin makefiles" but I >>>> have no Mac machine to copy/past the output of cmake --help. >>>> >>>> I am also using it in gst-plugins-gl. So I can help. >>>> >>>> Moreover, CMake can generate installers >>> Some questions that come to mind: >>> * How easy is it to teach it new build systems (S60 and Android come >>> to mind here). That includes Makfile, auto-generated files, etc... If it >>> can... this would ease the portability work of GStreamer (and plugins) a >>> *LOT*. >>> * What are the compile-time dependencies ? How easy/hard would it be >>> to use it in a cross-compile setup ? Can it run in esoteric setups ? If >>> we can gain new systems but lose old systems (on which auto* works >>> perfectly well due to only requiring a shell) it's gonna be a definite >>> blocker. >> >> As far as i know, CMake is similar to Autotools, in the sense that >> you just need it to process the configuration files. Then you can >> choose between creating standard makefiles if you want to use it in a >> shell environment, or creating Visual Studio projects if you want to >> use an IDE. >> >>> CMake looks *very* tempting (he who has read the libtool code with >>> love throws the first stone), but we need to make sure we're not losing >>> anything if we switch. >>> >>> Edward >>> > > If the CMake people would only have picked a decent syntax for the CMakelist.txt > files .... > them here: http://www.bakefile.org/wiki/ComparisonsWithOtherTools -- Ali ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
2009/3/26 Ali Sabil <[hidden email]>:
> On Wed, Mar 25, 2009 at 9:48 PM, Stefan Kost <[hidden email]> wrote: >> Andoni Morales schrieb: >>> 2009/3/25 Edward Hervey <[hidden email]>: >>>> On Wed, 2009-03-25 at 17:55 +0100, Julien Isorce wrote: >>>>> Hi, >>>>> >>>>> 2009/3/25 Andoni Morales <[hidden email]> >>>>> >> please add a link to codeblocks. >>>>> > >>>>> > The Code::Blocks home page is: http://www.codeblocks.org/ >>>>> > Julien Isorce is also using this IDE for gst-plugins-gl >>>>> > >>>>> >>>>> I forgot to mention that Code::Blocks can also be used to >>>>> compile >>>>> GStreamer in Mac OS X and to cross-compile GStreamer in Linux >>>>> >>>>> I like codeblocks but the best choice is to use CMake. >>>>> ( http://www.cmake.org/ ) >>>>> It's the most easiest, usable, viable, extensible etc... build system >>>>> known. >>>>> Qt and KDE are using it now. >>>>> CMake can generate codeblocks projects and more. >>>>> >>>>> CMake is cross platform. It can generate those things: >>>>> >>>>> Unix Makefiles = Generates standard UNIX makefiles. >>>>> CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. >>>>> Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project >>>>> files. >>>>> KDevelop3 = Generates KDevelop 3 project files. >>>>> KDevelop3 - Unix Makefiles = Generates KDevelop 3 project files. >>>>> Borland Makefiles = Generates Borland makefiles. >>>>> MSYS Makefiles = Generates MSYS makefiles. >>>>> MinGW Makefiles = Generates a make file for use with mingw32-make. >>>>> NMake Makefiles = Generates NMake makefiles. >>>>> Unix Makefiles = Generates standard UNIX makefiles. >>>>> Visual Studio 6 = Generates Visual Studio 6 project files. >>>>> Visual Studio 7 = Generates Visual Studio .NET 2002 project files. >>>>> Visual Studio 7 .NET 2003 = Generates Visual Studio .NET 2003 >>>>> projectfiles. >>>>> Visual Studio 8 2005 = Generates Visual Studio .NET 2005 project >>>>> files. >>>>> Visual Studio 8 2005 Win64 = Generates Visual Studio .NET 2005 Win64 >>>>> project files. >>>>> Visual Studio 9 2008 = Generates Visual Studio 9 2008 project files. >>>>> Visual Studio 9 2008 Win64 = Generates Visual Studio 9 2008 Win64 >>>>> project files. >>>>> Watcom WMake = Generates Watcom WMake makefiles. >>>>> CodeBlocks - MinGW Makefiles= Generates CodeBlocks project files. >>>>> CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. >>>>> Eclipse CDT4 - MinGW Makefiles = Generates Eclipse CDT 4.0 project >>>>> files. >>>>> Eclipse CDT4 - NMake Makefiles = Generates Eclipse CDT 4.0 project >>>>> files. >>>>> Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project >>>>> files. >>>>> >>>>> CMake can also generate XCode projects, and "darwin makefiles" but I >>>>> have no Mac machine to copy/past the output of cmake --help. >>>>> >>>>> I am also using it in gst-plugins-gl. So I can help. >>>>> >>>>> Moreover, CMake can generate installers >>>> Some questions that come to mind: >>>> * How easy is it to teach it new build systems (S60 and Android come >>>> to mind here). That includes Makfile, auto-generated files, etc... If it >>>> can... this would ease the portability work of GStreamer (and plugins) a >>>> *LOT*. >>>> * What are the compile-time dependencies ? How easy/hard would it be >>>> to use it in a cross-compile setup ? Can it run in esoteric setups ? If >>>> we can gain new systems but lose old systems (on which auto* works >>>> perfectly well due to only requiring a shell) it's gonna be a definite >>>> blocker. >>> >>> As far as i know, CMake is similar to Autotools, in the sense that >>> you just need it to process the configuration files. Then you can >>> choose between creating standard makefiles if you want to use it in a >>> shell environment, or creating Visual Studio projects if you want to >>> use an IDE. >>> >>>> CMake looks *very* tempting (he who has read the libtool code with >>>> love throws the first stone), but we need to make sure we're not losing >>>> anything if we switch. >>>> >>>> Edward >>>> >> >> If the CMake people would only have picked a decent syntax for the CMakelist.txt >> files .... >> > There are other problems with CMake (besides the syntax), you can find > them here: http://www.bakefile.org/wiki/ComparisonsWithOtherTools For me KDE is one the best examples of multi-platform project. This article explains why and how they switched to CMake: http://lwn.net/Articles/188693/ I think it's worth the reading. Andoni > > -- > Ali > > ------------------------------------------------------------------------------ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > ------------------------------------------------------------------------------ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |