David Hogan a ?crit :> That said, we don't use the supplied project. We simply compile in > the speex .c files. You could easily replace the Win32 build files > with a readme showing which .c files NOT include in your project > file. > > If you'd like, I'd be happy to produce a readme file on how to make a > VC project file for speex. Although this approach would require a > small amount of effort by each user, it would be resistant to being > made obsolete by either new .c files or a new compiler release, and > could be maintained by the same person maintaining the autoconf build > system.So far, it seems like the most sensible idea I've heard on that topic. It probably wouldn't be hard to have a small script that produces an exact list of files from the autotools files. Another advantage is that those who can't figure out how to create a project from these instructions probably shouldn't be using Speex to begin with :-) Jean-Marc
On Fri, Oct 3, 2008 at 7:15 AM, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote:> David Hogan a ?crit : >> That said, we don't use the supplied project. We simply compile in >> the speex .c files. You could easily replace the Win32 build files >> with a readme showing which .c files NOT include in your project >> file. >> >> If you'd like, I'd be happy to produce a readme file on how to make a >> VC project file for speex. Although this approach would require a >> small amount of effort by each user, it would be resistant to being >> made obsolete by either new .c files or a new compiler release, and >> could be maintained by the same person maintaining the autoconf build >> system. > > So far, it seems like the most sensible idea I've heard on that topic. > It probably wouldn't be hard to have a small script that produces an > exact list of files from the autotools files. Another advantage is that > those who can't figure out how to create a project from these > instructions probably shouldn't be using Speex to begin with :-)I hate to see every user do the same work, which can be done by a one user for everyone benefit. Every time VS projects become outdated, someone come up with a solution and this gets fixed very soon. I don't see why you should bother about this, keeping in mind you don't use VS - users of VS (me included) maintain them quite well, answer questions of other users and never blame you for VS build system breakage. These files are even located in separate directory! If you don't like this directory - rename it to .win32 and it will disappear from you 'ls' output. I'd say - do whatever you want, even cross-compile official windows binaries from Linux, but don't make your users upset by telling them they should do the work someone have already done. PS With cross-compiling from Linux there is a subtle point. Some users want to have static library, and some users want to compile for WinCE, which is easy to achieve if you have project files. PPS And please, don't forget, that we need to compile two libraries (libspeex and libspeexdsp) and a good bunch of test/example programs. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000
Alexander Chemeris a ?crit :> I hate to see every user do the same work, which can be done > by a one user for everyone benefit. Every time VS projects become > outdated, someone come up with a solution and this gets fixed > very soon. I don't see why you should bother about this, keeping > in mind you don't use VS - users of VS (me included) maintain > them quite well, answer questions of other users and never > blame you for VS build system breakage.When was the last time all project files were up-to-date in a Speex release?> These files are even > located in separate directory! If you don't like this directory - rename > it to .win32 and it will disappear from you 'ls' output. I'd say - > do whatever you want, even cross-compile official windows > binaries from Linux, but don't make your users upset by > telling them they should do the work someone have already done.It's not about seeing the win32 directory. It's about carrying 1MB worth of files that a out-of-date more often than not when it takes just a few minutes to create a new project.> PS With cross-compiling from Linux there is a subtle point. > Some users want to have static library, and some users > want to compile for WinCE, which is easy to achieve if you > have project files.Again, consider when's the last time I had win32 builds on time for the release. Not blaming anyone here, just showing how much of a mess win32 is to maintain in the current way.> PPS And please, don't forget, that we need to compile > two libraries (libspeex and libspeexdsp) and a good bunch > of test/example programs.Is it that much of a problem? Jean-Marc
Hi there, Alexander Chemeris wrote:> On Fri, Oct 3, 2008 at 7:15 AM, Jean-Marc Valin >>David Hogan a ?crit : >>>That said, we don't use the supplied project. We simply compile in >>>the speex .c files. You could easily replace the Win32 build files >>>with a readme showing which .c files NOT include in your project >>>file. >>[...] >>So far, it seems like the most sensible idea I've heard on that topic. >>It probably wouldn't be hard to have a small script that produces an >>exact list of files from the autotools files. Another advantage is that >>those who can't figure out how to create a project from these >>instructions probably shouldn't be using Speex to begin with :-) > > I hate to see every user do the same work, which can be done > by a one user for everyone benefit.Seriously: does this really mean so much work to you? When I started playing around with Speex, I unpacked the tar file, dragged all Speex source file into the VS project manager, deleted all that contained a 'main' routine, done (those are quickly identified by the linker's "duplicate symbol" errors :-). This took about five minutes. Finding the VS project of the right type, checking whether it's current, and hooking that into my VS project wouldn't have been faster. That aside, of course the VS compiler can also be used from a Makefile. The compiler is "cl.exe". I compile most of my stuff this way, especially because this way I need just one Makefile for all VS versions. Most of the time, it is a variation of OBJS = file1.obj file2.obj file3.obj CC = cl foo.exe: $(OBJS) $(CC) -Fefoo.exe $(OBJS) .c.obj: $(CC) -c $*.c Doesn't look much different from a 'nix Makefile to me.> PS With cross-compiling from Linux there is a subtle point. > Some users want to have static library, and some users > want to compile for WinCE, which is easy to achieve if you > have project files.This is also easy if you have a configurable Makefile. Stefan